【恐怖】主キーがないテーブルみたことありますか？
制約つけるの嫌いな人はいるよね。
でも、ER図やテーブル定義書に
「受注と受注明細は"0...*"の関係にある」
「受注.確定フラグは、0:未確定、1:仮受注、2:確定の意」
って書くなら、foreign-key制約つけてcheck制約つけてほしい。
「だってテストデータ作るときに面倒じゃないですか」とか
言われるんだけど、設計はしたけど実装しないってのは
手抜き工事みたいなもんだ。
でも、ER図やテーブル定義書に
「受注と受注明細は"0...*"の関係にある」
「受注.確定フラグは、0:未確定、1:仮受注、2:確定の意」
って書くなら、foreign-key制約つけてcheck制約つけてほしい。
「だってテストデータ作るときに面倒じゃないですか」とか
言われるんだけど、設計はしたけど実装しないってのは
手抜き工事みたいなもんだ。
|
|
|
783 ：NAME IS NULL：2007/01/28(日) 15:15:55 ID:???
FKは遅くなるから付けないってのが一般的では
784 ：NAME IS NULL：2007/01/28(日) 15:46:26 ID:???
制約に関しては、ケースバイケースなんだろうなぁ。
漏れはNOT NULLは積極的につける派だけど、
FKは時と場合で、フレームワークとかの比較的最新の技術で
組む時はFKだけど、COBOLとかの古代言語系の時は
つけない。と言うかCOBOLerが理解できないだろうし、
更新系で速度命の場合は、つけないけど。
ただ速度云々に関しては制約つけた方が安全性が高まるから
少しばかし遅くなっても制約つけるべきだとｵﾓ。
オペレータが２重にJOB起動させたけど制約で例外が発生して
助かった例もあるしな。
漏れはNOT NULLは積極的につける派だけど、
FKは時と場合で、フレームワークとかの比較的最新の技術で
組む時はFKだけど、COBOLとかの古代言語系の時は
つけない。と言うかCOBOLerが理解できないだろうし、
更新系で速度命の場合は、つけないけど。
ただ速度云々に関しては制約つけた方が安全性が高まるから
少しばかし遅くなっても制約つけるべきだとｵﾓ。
オペレータが２重にJOB起動させたけど制約で例外が発生して
助かった例もあるしな。
785 ：NAME IS NULL：2007/01/28(日) 16:03:11 ID:???
FKは逆方向の索引をつけるかどうか悩む。
786 ：NAME IS NULL：2007/01/28(日) 22:00:55 ID:???
制約の話は定期的に出てくるなあ。
787 ：NAME IS NULL：2007/01/29(月) 10:03:31 ID:???
制約はデータの整合性を保つ最後の砦だと思ってるので付けるなぁ
788 ：NAME IS NULL：2007/01/29(月) 20:50:17 ID:???
うちではこんな感じで使い分けています。
主キー制約、ユニーク制約：索引と密接にかかわるのでもちろん使う
NOT NULL制約：もちろん使う
CHECK制約：アプリ任せでほとんど使わない
参照整合性制約：
親子レコードのケースでは基本的に使う
複数の箇所で使うようなコードには基本的に使わない
主キー制約、ユニーク制約：索引と密接にかかわるのでもちろん使う
NOT NULL制約：もちろん使う
CHECK制約：アプリ任せでほとんど使わない
参照整合性制約：
親子レコードのケースでは基本的に使う
複数の箇所で使うようなコードには基本的に使わない
789 ：NAME IS NULL：2007/02/01(木) 21:52:15 ID:???
とりあえず制約は付けておくね。
最後にパフォーマンスが微妙に足りないときに削るかどうか考えるw
結合テスト段階で制約違反出した奴はペナルティww
最後にパフォーマンスが微妙に足りないときに削るかどうか考えるw
結合テスト段階で制約違反出した奴はペナルティww
790 ：NAME IS NULL：2007/02/02(金) 22:26:15 ID:???
参照整合制約の何が嫌かって、インポート時に制約で引っかかるのが嫌
791 ：NAME IS NULL：2007/02/04(日) 04:05:45 ID:???
792 ：NAME IS NULL：2007/02/06(火) 01:02:22 ID:???
>790
インポート時に制約を無効にすればいいじゃない
インポート時に制約を無効にすればいいじゃない