Hatena::ブログ(Diary)

kguの日記

2010-11-23

サロゲートキーを使用した感想

| 12:23 |

現プロジェクトのDBでは、設計方針としてサロゲートキーを導入している。

サロゲートキーとは、テーブルの主キーとして導入された業務上の意味を持たない連番などのキーのこと。

現プロジェクトでは、以下のような方針で設計した。

  1. テーブルには、ID項目を持たせ、それを主キーにする。(ID項目はシーケンスで採番)
  2. ID項目を持たせたテーブルの業務上主キーとなる項目は、一意キーにし、NOT NULLにする。
  3. 各テーブルの関連は、ID項目を参照することで実現する。

上記の方針で設計した結果、以下のメリット、デメリットがあった。

    メリット
  1. 結合が楽。
    結合キーは基本的にIDという単一項目であるため、複合キーを結合するより楽である。

    デメリット
  1. 業務上のキーの一部を条件に、一括した更新/削除ができない。
    関連の紐付けは、ID項目でのみ行っているため。
  2. DELETE/INSERTが制限される。
    例えば、AテーブルにひもづくBテーブルがある場合、AテーブルのデータをDELETE/INSERTすることはできない。
    シーケンスで採番しているIDが変わってしまうため。

デメリット1については、一括更新に使いたい項目も持たせればよいのだろう。
デメリット2については、DELETE/INSERT自体、安易にするべきものではないのかも。

導入するときは、デメリットを意識しておく必要がある。

通りがかり通りがかり 2011/03/04 00:25 サロゲートキーが問題なく使えるような要件およびテーブル
設計であれば、そもそも開発の難易度(規模ではない。)が
低いため、生産性は高いでしょうね。
メリットに複合キーを結合するより楽であるとありますが、
もちろんそれはその通りですが、
サロゲートキー設計では満たせないような業務要件がある
システムの方が圧倒的に開発難易度が高くなるため、
結果的に、楽に作れたシステムで採用されていたサロゲートキー
を過大に評価している人が多く見受けられる気がします。

トラックバック - http://d.hatena.ne.jp/kgu/20101123/1290482634
リンク元