代理キーとかサロゲートキーとか。の続き

ぐはあぁぁあ。
１つの棚に複数の商品が置けてもいいつもりだったのに、
１つの商品しか置けないモデルになってしまってますね。
というわけで考え直しました。

改善版

わたなべさんとid:bottleneckさんのモデルとの違いは・・・

倉庫棚を棚と倉庫_棚に分けている

「棚はあるんだけど、まだ商品が置けるように配置してないんだよねー」ってな場合に、倉庫棚エンティティで外部キーに倉庫IDが入ってると、倉庫IDにはNULLかダミー値を設定することになります。
それはイヤンな感じなので、棚の存在を独立して考え、倉庫に配置された棚は倉庫_棚エンティティにレコードを作るように考えました。

「商品と倉庫の組み合わせで棚が決まる」ルールと在庫を別にした

わたなべさんとid:bottleneckさんのモデルでは、在庫エンティティが「商品と倉庫の組み合わせで棚が決まる」ルールを含んでいますが、ルールが変わったとき（棚がいっぱいになっちゃったときとか）に在庫ってどうなるの？っていうのが疑問だったので、分ければいいじゃんな考えです。
この考えはわたなべさんのエントリのコメントでid:bottleneckさんも指摘していて、わたなべさんは

データ項目のライフサイクルが違いすぎる場合にはテーブルを分けることもありますが、
そういう意味でもこの場合は分ける必要はありませんね。

とおっしゃられてる。
うーん、そういうものなんでしょうか。
先々どうなるかわからないかもしれなくて、分けといたほうがベターな気がするのですが。。
立ち位置の違いってやつでしょうか。
確かにわたなべさんのモデルでも要件を十分に満たしているとは思います。
ここらへんの割り切り（？）みたいな判断が難しいなあと思います。

もうまったくサロゲートキーの話じゃなくなってしまった。。