制約っていらなくね？ (114ﾚｽ)
上下前次1-新
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
そういった事が出来れば火消しなんか使わないかと。
むしろ火消しが出来る人(又はグループ)を
予備選力としてヤバい所に投入ってのは防御の基本かと。
(史実の重戦車大隊みたいだな)
48: 43 04/07/21 18:53 ID:??? AAS
>>45
あたくしの場合、火消し役やらされてる間も
他の案件の保守で人月工数出とるんで
コストかかっとらんのですわ。
だから便利に使われるって訳です。疲れた・・・・。
49: 04/07/21 19:32 ID:??? AAS
納期間に合わなさそう
↓
新しい人材を大量投入
↓
スキル高い人の手間が、新しい人への引継や教育に取られる
↓
さらに炎上
こういうパターンが多いよな。
50: 04/12/01 18:41 ID:??? AAS
うちでは、主キー以外の制約はってません
それはＩＳＡＭ的なんでしょうか？
なんかＤＢＭＳの機能を使ってるきがしない
関連削除も不具合が発見されてから、整合性調整アプリを作ってるし
みんなはきちんと関連図みたいなんカタメテからやってるんですよね？
51: 04/12/02 18:05 ID:??? AAS
実はうちもです。
カスケードってなーに？
頑張ってアプリ側で実装ですよ。
52: 04/12/15 07:00 ID:6kA6XGLm(1) AAS
このスレっていらなくね？
53: 04/12/15 23:47 ID:??? AAS
あとから設計見てどういう意図で組んだのかわかりやすいから制約は付けてるなあ
どーせ突っ込む前にデータチェックするんだけどね
54: 05/01/04 23:49 ID:gtuR+WFj(1) AAS
制約かぁ・・・
参照性合成制約とかトリガーによるチェックはどうかと思うが、
主キーとNOT NULL制約は最低限付けた方が良いな。
55: 2005/03/29(火)17:51 ID:??? AAS
1 WEBからデータ入力（クライアントでのデータチェック）
2 サーバプログラムで加工（サーバでのデータチェック）
3 DBに格納（DBMSでのデータチェック）
なんかもどかしい.
上下前次1-新書関写板覧索設栞歴
あと 59 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.005s