前回まではアンチパターンやバッドノウハウについて学習してきましたが、今回はグレーノウハウについて特集します。
グレーノウハウとは読んで字のごとくホワイトともブラックとも言えないという手法ですね。
つまりある程度の効果もあるけれども、堂々と正しいとは言えない設計のことです。
ポイントとしては
- 完全に否定はできない
- 使うなら節度をもち、リスクを踏まえて
ということですね。それでは以下見ていきます。
Contents
主キーが存在しないときのサロゲートキー
データベースではコードなどのキーによってユニークな組み合わせをつくれることが理想です。こういったキーを主キーといい、一つのキーだけで特定できない場合は複数のキーを組み合わせる複合主キーを使用します。
そうはいっても実務では必ずしもユーザーが使用しているキーがユニークになるとは限りません。
- 使いまわしをしている
というケースも考えらなくはありません。
このようなケースで使われるのがシステム側が発行する代理キー(サロゲートキー)です。ユーザーが使用するものとは別にシステム側で自動採番されるような人工的なキーを生成します。
これはかなり一般的によく使われている手法ですが、
- そもそも論理的に不要なキーであり、論理モデルを分かりにくくする
などのデメリットもあり、無条件で奨励できるものではないようです。
できれば
使いまわしをしている場合は
- 年度や時間などを列として追加することで複合主キーとして解決できないかを検討する
といった解決策を考えるのが良いようです。
上記の内容ですが、メリットとデメリットを深く考慮してませんでした・・・いままで何も考えずにオートインクリメント属性のidを作成し、これを主キーとしてました・・・。このやり方に問題自体がないと思っていたので・・
うーんやっぱり理論的なことを知らないとまずいですね・・・
代理キー
ちなみに代理キーに関してもシーケンスオブジェクトを使用するパターンとオートインクリメントを使用するパターンの2種類があります。
私はMySQLがほとんどだったのでほとんどオートインクリメントでやってきましたが、データベースベンダーにより型が違っているなど、移植性がひくいというデメリットがあり、柔軟性という点ではシーケンスオブジェクトに軍配が上がります。
オートナンバリングをアプリ側でつくることもできますが、排他制御を考えたりと開発工数が増えるというデメリットがあります。
ちなみに代理キー自体はシーケンスオブジェクトでもオートインクリメントでもアクセスが集中した時に性能遅延するというデメリットがあります。
[…] 論理設計のグレーノウハウ サロゲートキー […]