Chapter 12. Object-Relational Structural Pattern に突入しました。
初回は Identity Field で、これを原著から直接引用すると
In essence, Identity Field is mind-numbingly simple. All you do is store the primary key of the relational database table in the object's fields.
となりまして、意訳すると「本質的に、Identity Field は退屈なくらい単純だ。単に RDB 上のテーブルの主キーの値をオブジェクトのフィールドに突っ込むだけだ」ということになります。 ただ、何かその記述ページ数が非常に長くて骨が折れました。いや、内容は面白いんですけどね。
主キーの選択
主キーの選択というのはテーブル設計の中で盛り上がるところなんですけど、設計の中には
- サロゲートキーが良いのか、ナチュラルキーが良いのか
- サロゲートキーの場合、その主キー値はテーブル毎にユニークとするのか、データベースでユニークとするのか
ていう観点があったりします。前者については、サロゲートキーと複合主キー | DBFlute
Identity Field っていうのはスゴくシンプルな話なんですけど、上記のような選択肢のそれぞれについて議論されているので説明としては長くなっており、読むのもしんどくなっているんですが、本質的にはやはりシンプルです。 ぼくは、論理設計ではナチュラルキーをベースとして考えた上で物理設計まで落としたときはサロゲートキーを使用する、主キー値はテーブル毎にユニークっていうのが多いです。テーブル毎にユニークにするのは、主キーの採番テーブルなんてのを用意するケースで、その採番がボトルネックになるのを防ぐためですね。
主キー値の採番
サロゲートキーを使用するにあたって、その型は long を使うのがスタンダードという話は納得しました。 この生成方法には主に 4 つの方法があります。
- Auto-generated field を使用する
- MySQL の auto-increment を使用するとか
- database counter を使用する
- Oracle の SEQUENCE を使用するとか
- wikipedia:GUID を使用する
- 自前で採番する
- 採番用テーブルを使用する
個人的には DBMS が固定されているんだったらその機能を使うのが良いと思っていて、auto_increment とか SEQUENCE とか使ったら良いんじゃないかと思っています。 SQL も DB の型もベンダ依存多いんだし、DBMS 変えるっていう頻度を考えれば、それなりの変更コストが伴うことを前提に、開発と保守の生産性を上げる方が良いんじゃないかと。 というわけで、1 や 2 が好みの方法です。
