Hibernateちょい近くなりました。
WEB+DB Press Vol.28に載ってた、はぶさんのモデリングの記事を読んで、なぜか(?)Hibernateが身近なものとなりました。
分かりやすい例でいうと、
- 顧客(顧客コード、顧客名)
- 商品(商品コード、商品名、単価)
- 注文(顧客コード、商品コード、数量)
みたいなモデルがあった場合、顧客と商品の関連表となる注文には、論理上顧客コードと商品コードの複合キーとなる必要がありました。この複合キーというのが、Hibernateでは扱いづらい。Associationを定義するのにもやっかいです。以前その使いづらさは書きました。
http://d.hatena.ne.jp/taka_2/20050719#p2
しかし、ここに代替キーとして、IDという概念を導入するというのです。
つまり、
- 顧客(ID、顧客コード、顧客名)
- 商品(ID、商品コード、商品名、単価)
- 注文(ID、顧客.ID、商品.ID、数量)
ということです。
こうすることによって複合キーを排除できるので、分かりやすくなり、またAssociationなどの定義もやりやすくなります。
注文→顧客(many-to-one)、注文→商品(many-to-one)って感じですね。
以前、このようなテーブル構造を採用しているところで、運用上、コード体系の見直しっていうのが顧客によって行われたのですが、この場合、キー自体を変えるわけではないので、変更に対するリスクが低かったと思います。
