以前にも書いたのですがデータペースの主キーに対して誤解している設計者を見かけます。自己学習しないで、OJT(サンプルや雛型含む)が正しいと認識している人に多く居る気がします。
データベースの主キーは十分条件であって必要条件ではありません。キーや索引を張らないほうがコストが安い場合も多々あります。
例) 顧客の住所マスタの変更に対して変更履歴を保持するのは良くあることでする。
マスターに対して追加/変更/削除のトリガーで履歴データを作成するのが一般的でしょう。
単純な項目構成で考えて見ますコード、氏名、住所 の三項目とします。履歴テーブルは (追加or変更or削除識別)、コード、氏名、住所、日時という構成にします。
(少し手を抜いて、マスターのレイアウトと履歴レイアウトを同一にする時もあるのは内緒です..www)
ここで変更履歴に主キー/索引の設定の是非問題がでてきます。もちろん変更履歴が実運用上頻繁に参照されるケースもあります。原紙伝票発生時点での顧客の住所を印刷する仕様などはそうなります。其の際には索引の設定は必要です。ここではこのような使用はしないものとします。
変更履歴の使用目的が、単純な履歴の保持だけに限定される場合は、主キー、索引の設定はなくてもいいですね。ところが、顧客コート+日時で主キーを張っているテーブルを見かけます。 「なぜ張るの?」と効くと、「なんでそんなこと突付かれるの。主キーは必須なので、この項目でユニークになる組み合わせはこれしかないから当然こうなるでしょ。」と不満が顔に出てます。
変更履歴の参照頻度と索引が有ることによる、追加・変更コストを考えると結論は直ぐでます。
OJTはノウハウの習得には効率的なんですが、基礎知識の一部が欠落しがちです、欠落部分を補う仕組みが要りますね。何が欠落しているか知るのも難しいし。私も欠落している知識が多いし。なにが欠落しているか通知してくれるEducationSoftが欲しい。あれば買いたい。