エンティティ設計について僕の意見が少数派だったので意見を述べておきたい
主キーに業務キー（複数キー）を利用する設計について
しんさん のブログを見て、ものすごく共感したので一言。
おそらく、これはHibernate、Rails、Grailsなどを学んだ多くの方が感じていることではないかとおもいます。
僕も、今の職場でデリゲートキーを考慮したエンティティ設計を提案するとかなり叩かれます。「その設計、わかりにくい」とか、「主キーは業務キーにした方が早いのは当然」とか、「項目が多いと保守が大変」とか。
しんさんと言う通り、デリゲートキー（ID）導入するとエンティティ洗い出しやリレーション設計時には、エンティティの詳細情報を後回しに出来ます。抽象的な設計と具体的な設計が綺麗にわけれます。基本設計といわれる工程ですべき作業に注力できます。
業務キーを主キーにした場合の最悪なケース
子テーブルが親テーブルの主キーを引き継ぐ設計で苦しんだことがあります。
実際にプロジェクトであった話を。
以下のようなテーブルがあります。
- テーブルAの主キー :
x - テーブルBの主キー :
x,y - テーブルCの主キー :
x,y,z
テーブルA と テーブルB は1:n、 テーブルB と テーブルC は1:nの関係です。
ここで テーブルA にキー項目aが追加になった場合には、 テーブルB 、 テーブルC にもキー項目aを追加する必要がでてきます。つまり、 変更に弱い設計になります 。
デリゲートキーを使用した設計の場合には テーブルA にキー項目aを追加して終了です。
また別のプロジェクトでは、同様の設計により以下のようになっていました。
- テーブルAの主キー :
x1, x2, x3, x4 - テーブルBの主キー :
x1, x2, x3, x4,x5 - テーブルCの主キー :
x1, x2, x3, x4,x5,x6
キーを何個もつのかと。このように 主キーが無駄に肥大化していく傾向もあります。
参照整合性制約は張らない設計もあるけどアレはなに？
こちらもよくあるのですが、「参照整合性制約ははらないでください。」という方針。なぜかを尋ねると、「開発が大変だから。」だそうです。あとは考慮することが増えていろいろ面倒だ、とか。
僕には 参照整合性制約 を張らないほうが考慮することが増える気がするのですが・・・
トランデータで参照しようとするマスタがデータが存在しない場合はどうするの？参照されているマスタが削除された場合は？
職場のほとんどの方が僕の経験不足を指摘しますが、そういうものなのでしょうか？