Uenishi.Web

最近、PL/SQLの作成やテーブル設計などのタスクも少し出てきたので、個人的DB強化月間としてつらつらと書いていきます。まずはナチュラルキーとサロゲートキーについて。

キーそのものに意味が含まれていて、業務的にそのテーブルをユニークにする。

入力データ自体がPKになる。

業務上では意味を持つ値ではないが、システム的に一意な値をとるようにオートインクリメントなどで連番を振ったPK。

下記のように「それだけでは意味を持たない」ユーザーNoを、システム上で別途採番してPKとしているとサロゲートキーになります。

メリット

• 主キーに対して制約やインデックスを設定する必要がない
• ぱっと見データ構造が把握しやすい

デメリット

• 変更による影響が大きい

メリット

• SQLが簡潔になる
• テーブル間の依存関係が薄くなる

デメリット

• 本来不要な値を保持するため、余分なデータ容量を使う
• 実質的な主キー項目に別途制約やインデックスを設定する必要がある

サロゲートキーは業務的に必要がない値をテーブルに持たせますが、ナチュラルキーだけでは開発を進めていく上で困難なシーンも発生するため、それぞれのメリットとデメリットを理解し、適材適所で活用していくのがいいとされています。

ナチュラルキーとサロゲートキーのどちらでテーブル設計をすれば良いか、各所では色々な論争が繰り広げられいます。

にも書かれているように、自然キー以外を主キーに使うことを厳しく批判する声もありますが、実際の現場で言うとサロゲートキーは結構使われているように感じます。

現実的に、仕様変更が発生しそうな場合の考慮などでサロゲートキーが使われることが多いのかなという感想です（テーブル感の依存関係が薄くなるため、変更に関わる影響範囲が少なくなる）。

まだまだテーブル設計の経験値が少ないですが、それぞれ「どちらがいいか」という観点ではなく、「どちらが適切か」という観点で見ていけるように鍛えて（？）いきたいなと思います。