制約っていらなくね？ (114ﾚｽ)
上下前次1-新
28: 26 04/07/09 10:17 ID:??? AAS
制約自体に罪はない、設計がアレなだけだ、って事ですね。
今まで誤解してたよ、ごめんよ、制約。
全てアプリ側でコントロールすると
>21みたいな事にもなるしね。
これからは心を入れ替えて制約も活用してみます。
皆さん具体的にどうですか？
制約使って便利だーいやトラブったーとかあります？
外部キーとかってどうしても使う勇気が湧かないんですよ。
ただ新しい事やりたくないってだけなんですが。
29(8): 04/07/10 18:41 ID:+BBjcTFg(1) AA×
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.030s