制約っていらなくね？

制約っていらなくね？ (114ﾚｽ)
上下前次 1-新

38(1): 29 04/07/11 10:23 ID:??? AA×
>>37 >>35

38: 29 [sage] 04/07/11 10:23 ID:???

>>37
すみません、まだ計測できる段階じゃなくて・・・
もちろんテスト用にデータがそろえば計測してみます。
だけど、NOT EXISTS が AND でいっぱい並ぶってことは、削除対象レコードであることがわかるためには
対象テーブルの全行を全検索することになるので、どうなんだろうと思うわけです。
INDEX 付ければ速くなるでしょうが、ログテーブルを逆引きするためにいちいち INDEX の領域とるのはなぁ、
と躊躇してしまいます。
といってもそれは、他になにか手段があるはずだと思ってるから、選択肢として後回しにしてるに過ぎない
のですが。

>>DBの内部では、外部キーに参照されたレコードが削除されるときに、そのことを瞬時に把握する仕組みを持っているはずで、
>
>ふつう、そんなものはない。

そうなんですかね？
ON DELETE CASCADE 指定されたときはいざ知らず、ただの外部キーにより参照されてるカラムは、内部的に
被参照カウンタでも持ってるんじゃないかな、と勝手に推測したのですが。
というのは、>>35 のやり方をやったとき、
TABLE_FK には当然 TABLE_A に無い値は INSERT できないし、逆に TABLE_FK にある値は TABLE_A から削除できません。
これは期待する動作ですよね。
ところが TABLE_FK を継承した TABLE_B、TABLE_C へは、 TABLE_A に無い値でも INSERT できてしまいます。
で、TABLE_FK を　SELECT してみれば、やっぱり TABLE_A に無い値を持つレコードができてしまっています。
たとえばその値が 100 だったとして、関節的にTABLE_FK に TABLE_A に無い 100 を INSERT して、次に TABLE_A に
100 を INSERT して、さらに TABLE_A からその 100 を DELETE してみると、TABLE_FK に 100 を持つ値があるのに
DELETE できてしまいます。

ということは、TABLE_A が削除されるときに、外部キー参照しているテーブルをいちいち検索しに行ってるわけでは
ないのかな、と思ったのですが、いかがでしょう？

しかし、継承させたテーブルで継承元の制約が受け継がれないってのは、一般的な仕様なのでしょうか。
それとも PostgreSQL のバグですかね？

http://mevius.5ch.net/test/read.cgi/db/1087483786/38

上下前次 1-新書関写板覧索設栞歴

あと 76 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.049s