DDLレベルの外部キー制約は不要 - 設計者の発言

テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注

[JHashimoto]

"テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるため、業務ルールに関する記述があちこちに散らばってしまうからだ。"

[iakio]

動的参照か

[sh2]

「「開発基盤」がその役目を果たせばよい」PeopleSoftがそんな感じかなあ

[tsucchi1022]

モデリングの面での FK の話

[ktakeda47]

"ようするにDDLレベルの外部キー制約機構は、現実の業務要件を前にしてはイライラさせられるほどに単純で中途半端である。"

[tgk]

「外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるため、業務ルールに関する記述があちこちに散らばってしまうからだ」

[terazzo]

DRYという意味では基盤側で記述すれば裏でDBに制約付けに行くのはアリかな。／「削除フラグ」の扱いをビューでやるか基盤側でやるかみたいなのも同じような感じか。

[airj12]

同意。

[rhosoi]

外部キー使うなって話じゃないんでちゃんと読むように(´∀｀)

[masaru_b_cl]

言わんとすることにはおおむね賛成なんだけど、ここだけは反対 > "「項目の見せ方」に関する諸問題は、じつは「ＤＢ側の事情」である。"