「複合キー」と実装用フレームワーク - 設計者の発言

テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルＡが「社員」で、Ｃが「趣味」で、ＡＣが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の５つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [Ａ] {a}, b ＋ 100 aaa

[torazuka]

"避けるべきなのは、個別の実装用フレームワークの枠組みを通して論理設計のあり方を帰納的に把握しようとすること" こういうメタな視点も持ってなかった。肝に銘じる。

[dagjmpd]

「複合キー」と実装用フレームワーク

[takami_hiroki]

より論理要件にあわせたDB設計とするべき。

[Hayato]

「論理要件により近い形で実装できるような環境（実装用フレームワーク）がベター」って、RDBMSが論理設計そのままでは実装できないものなので、代理キーなんだと思うんだ。