2008/10/18

エンティティ設計について職場で叩かれるの巻

主キーに業務キー(複数キー)を利用する設計について

しんさんのブログを見て、ものすごく共感したので一言。おそらく、これはHibernate、Rails、Grailsなどを学んだ多くの方が感じていることではないかとおもいます。

僕も、今の職場でデリゲートキーを考慮したエンティティ設計を提案するとかなり叩かれます。「その設計、わかりにくい」とか、「主キーは業務キーにした方が早いのは当然」とか、「項目が多いと保守が大変」とか。

しんさんと言う通り、デリゲートキー(ID)導入するとエンティティ洗い出しやリレーション設計時には、エンティティの詳細情報を後回しに出来ます。抽象的な設計と具体的な設計が綺麗にわけれます。基本設計といわれる工程ですべき作業に注力できます。

業務キーを主キーにした場合の最悪なケース

子テーブルが親テーブルの主キーを引き継ぐ設計も止めてほしい。実際にプロジェクトであった話を。

以下のようなテーブルがあります。

  • テーブルAのpk:x
  • テーブルBのpk:x,y
  • テーブルCのpk:x,y,z

テーブルAとBは1:n、テーブルBとCは1:nの関係です。

ここでテーブルAにキー項目aが追加になった場合には、テーブルB、Cにもキー項目aを追加する必要がでてきます。つまり、変更に弱い設計になります。デリゲートキーを使用した設計の場合にはテーブルAにキー項目aを追加して終了です。

また別のプロジェクトでは、同様の設計により以下のようになっていました。

  • テーブルAのpk:x1, x2, x3, x4
  • テーブルBのpk:x1, x2, x3, x4,x5
  • テーブルCのpk:x1, x2, x3, x4,x5,x6

キーを何個もつのかとw。このように主キーが無駄に肥大化していく傾向もあります。

参照整合性制約は張らない設計もあるけどアレはなに?

こちらもよくあるのですが、「参照整合性制約ははらないでください。」という方針。なぜかを尋ねると、「開発が大変だから。」だそうです。あとは考慮することが増えていろいろ面倒だ、とか。

僕には参照整合性制約を張らないほうが考慮することが増える気がするのですが・・・

トランデータで参照しようとするマスタがデータが存在しない場合はどうするの?参照されているマスタが削除された場合は?

 

職場のほとんどの方が僕の経験不足を指摘しますが、そういうものなのでしょうか?

0 件のコメント:

コメントを投稿