制約っていらなくね？ (114ﾚｽ)
上下前次1-新
28: 26 04/07/09 10:17 ID:??? AAS
制約自体に罪はない、設計がアレなだけだ、って事ですね。
今まで誤解してたよ、ごめんよ、制約。
全てアプリ側でコントロールすると
>21みたいな事にもなるしね。
これからは心を入れ替えて制約も活用してみます。
皆さん具体的にどうですか？
制約使って便利だーいやトラブったーとかあります？
外部キーとかってどうしても使う勇気が湧かないんですよ。
ただ新しい事やりたくないってだけなんですが。
29(8): 04/07/10 18:41 ID:+BBjcTFg(1) AAS
単にDBに値をチェックしてもらうだけならどうでもいいけど、関連レコードの自動削除みたいのはかなりいいと思うけどどうよ？
外部キーに ON DELETE CASCADE 付けとけば、親テーブルのレコードを削除するだけで紐付く子テーブルレコードも漏れなく削除できるよ。
ところで質問。
テーブルA とテーブルB があって、テーブルB はテーブルA の主キーを外部キーとして参照しています。
で、テーブルA のレコードに紐付くテーブルB が存在するかどうかを確認したいです。
できれば参照されている件数なんかも知ることができるといいです。
SELECT なりでも調べられますが、実は実際に扱おうとしているものは、テーブルA の主キーを外部キーとするテーブルがべらぼうに多くて、ちょっと大変です。
こんな感じになっちゃいます。
SELECT
TABLE_A.ID,
省8
30(1): 04/07/10 19:04 ID:??? AAS
大変つっても一回書きゃおしまいだろ？
31: 04/07/10 19:09 ID:??? AAS
>>30
処理にかかるコストの問題です。
32(1): 04/07/10 21:46 ID:??? AAS
>>29
TABLE_A.IDに ON DELETE NO ACCTION 付けて全行削除してみればいいんじゃないの？
33(1): 04/07/10 21:55 ID:??? AAS
コストの問題なら、>>29でどのくらい問題なのか書かんと。
34(1): 29 04/07/10 22:20 ID:??? AAS
>>33
現在はまだ実験してる段階なので、実際どのくらいの処理時間になるかはわかりませんが、やろうとしていることは次のようなものです。
このテーブルAはちょっとしたログテーブルみたいなもので、トランザクション毎に一行 INSERT されます。
で、そのトランザクション内で更新されたいろんなテーブルのレコードには、その TABLE_A.ID を記録します。
だからほっとくとテーブルAレコードは無限に増えて行きますし、TABLE_A.ID を外部キーとするテーブルの数も数十個あります。
また、更新を繰り返すうち、古いログ情報はどのテーブルからも参照されなくなるので、そうなったときには削除しなくてはなりません。
各テーブルの規模は、数十件くらいのものから数万件を超えそうなものまで様々です。
だから、>>29 にある SELECT で逐一被参照数をカウントするのは、ちょっと具合が悪そうだと推測できます。
まあ、必ずしも数を数える必要性は無いので、COUNT しようなんてことはせずに EXIST で各テーブルの参照の有無を調べて
ばっさり DELETE してしまってもいいですが、WHERE には結局数十個のテーブルについての EXIST が並ぶことになり、
省13
35(2): 29 04/07/10 22:59 ID:??? AAS
自己レスです。ちょっと思いついちゃいました。
テーブルAを参照する外部キーを、それ専用のテーブルにして、他のテーブルはそのテーブルを INHERITS すれば
具合がいい気がしてきました。
こんなかんじ。
CREATE TABLE_A (
ID INTEGER PRIMARY KEY,
DATA TEXT
);
CREATE TABLE_FK (
FK INTEGER NOT NULL REFERENCES TABLE_A(ID)
省12
36: 29 04/07/10 23:18 ID:??? AAS
たびたびすみません・・・
>>35 のやり方だと、TABLE_FK の外部キー制約は TABLE_B や TABLE_C に継承されないっぽいです。
TABLE_B、TABLE_C それぞれで外部キー制約を付ける必要があるようです。
ハマるところだった・・・
危ない危ない。
37(1): 名無しさん＠そうだ選挙に行こう 04/07/11 09:19 ID:??? AAS
>ばっさり DELETE してしまってもいいですが、WHERE には結局数十個のテーブルについての EXIST が並ぶことになり、
>パフォーマンスは悪そうです。
数十個といっても加算的なものだし。
逆にテーブルが3個しかないなら期待するパフォーマンスが出る
という保証はないから、まずは計測してみれ。
>>34を読む限りでは、テーブル3個の場合のパフォーマンスにも
満足できなそうに思えるんだが。
>DBの内部では、外部キーに参照されたレコードが削除されるときに、そのことを瞬時に把握する仕組みを持っているはずで、
ふつう、そんなものはない。
ON DELETE CASCADEも結局、トリガで対象のテーブルから
省1
38(1): 29 04/07/11 10:23 ID:??? AAS
>>37
すみません、まだ計測できる段階じゃなくて・・・
もちろんテスト用にデータがそろえば計測してみます。
だけど、NOT EXISTS が AND でいっぱい並ぶってことは、削除対象レコードであることがわかるためには
対象テーブルの全行を全検索することになるので、どうなんだろうと思うわけです。
INDEX 付ければ速くなるでしょうが、ログテーブルを逆引きするためにいちいち INDEX の領域とるのはなぁ、
と躊躇してしまいます。
といってもそれは、他になにか手段があるはずだと思ってるから、選択肢として後回しにしてるに過ぎない
のですが。
>>DBの内部では、外部キーに参照されたレコードが削除されるときに、そのことを瞬時に把握する仕組みを持っているはずで、
省17
39(1): 名無しさん＠そうだ選挙に行こう 04/07/11 12:15 ID:??? AAS
>>38
TABLE_B.IDとかには当然indexを設定していると思っていたんだが。
>INDEX 付ければ速くなるでしょうが、ログテーブルを逆引きするためにいちいち INDEX の領域とるのはなぁ、
本当にdeleteのパフォーマンスが問題ならindexを作る。パフォーマンスを
犠牲にしてでも領域を節約する必要があるなら作らない。
ディスク領域を気にしているようだが、じゃあこれらのテーブルにどのくらいの
レコードが登録されてどれくらい領域を必要とするか見積もってる？
チューニングの話なら「遅そう」「領域食いそう」とかの感覚的な話じゃ
先に進まないよ。そのへん見積もれないうちから小手先のテクニックを
弄しても無駄に終わる可能性が高いから、まずは正攻法でやってみれ。
省9
40(1): 名無しさん＠そうだ選挙に行こう 04/07/11 16:54 ID:??? AAS
>>29
もう少し手短にまとめてくれ。読むのがめんどくさい。
一般的に速度と記憶域はトレードオフ。実際に手を動かさずに、いつまでも机上の
空論を弄んで、根拠のない妄想に見切りつけずにあれこれ悩むのは時間の無駄。
そもそも更新速度の低下でならまだしも、記憶域を圧迫する理由でインデックスを
張るのを躊躇するような貧相な環境なら、まず環境を見直すべき。
41: 29 04/07/12 02:30 ID:??? AAS
>>39,40
文章得意じゃなくて、端的に書けなくてｽﾏｿ。
INDEX を張るのを躊躇した理由は、容量の問題だけではなくて更新時のパフォーマンスも気にしてのことです。
さらに言うと、実はTABLE_A.ID への外部キーは、一つのテーブルあたり挿入時用、更新時用、削除マーク用の 3つあるので、
容量もINDEX更新のコストも3倍かかりそうで、なおさら気になったのです。
自分はINDEXに必要なディスクスペースや、INDEX更新に必要なコストを見積もるスキルは無いのですが、せっかく制約の
スレを見つけたので、制約に関する便利機能なんかの意見をもらえるかな、と思っての質問でした。
自分でも結局は INDEX 張って正攻法でやることになるんだろうな、と思っています。
> たしかに、継承するなら制約やトリガなども継承された方が便利だと
> 思うんだけどね。
省14
42(1): 04/07/21 01:04 ID:??? AAS
制約やデフォルト値を細かく指定しておくと
ドキュメントがないとか，前任者が遁走した時の場合でも
ある程度何をしたかったかがわかるのでよい
43(1): 04/07/21 10:57 ID:??? AAS
>>42
うんうん、わかるわかる（泣）。
俺、火消し役ばっかりやらされてるんで。
でも、遁走するような奴の設計には
懐疑的になってしまうのもまた事実ですね。
でも何も無いよりいいか。
44: 04/07/21 11:11 ID:??? AAS
適当な設計やっても平気で提案できるくらいの奴は、
神経が図太い場合が多いから、逆に辞めない。
間違った仕様を正したいのに、認められなくて
耐えられなくなって辞める奴の方が多い。
憎まれっ子世にはばかる。
45(3): 04/07/21 11:12 ID:??? AAS
関係ないけど、火消しを入れる予算があるのなら、
最初から出火させない人を雇えよと思ったりもする。
火消し担当の人が、最初からプロジェクトに関わればいいのに。
46: 04/07/21 11:22 ID:??? AAS
>>45
自然発火とか
47: 04/07/21 16:48 ID:??? AAS
>>45
そういった事が出来れば火消しなんか使わないかと。
むしろ火消しが出来る人(又はグループ)を
予備選力としてヤバい所に投入ってのは防御の基本かと。
(史実の重戦車大隊みたいだな)
上下前次1-新書関写板覧索設栞歴
あと 67 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.009s