入れ物と中身

とある箱Aにリンゴを入れるとします。
さらに、ある日を境に箱Aの中身をリンゴ→ミカンに入れ替えるとします。

表にするとこんな感じです。

入れ物	中身	期間
箱A	リンゴ	12/01-12/10
箱A	ミカン	12/11-12/20

これを入れ物、中身、期間（バージョン）でそれぞれテーブル分割してみます。

名前	色
箱A	赤

→各箱の固有の情報が入っています。
　ここには"箱B（青）"とかも入れられます。

名前
リンゴ
ミカン

→中身に関する情報のみです。

バージョン	期間
1	12/01-12/10
2	12/11-12/20

→バージョン（期間）を管理するテーブルです。

これら3つ(+中間テーブル)でER図を書くとこんな感じです。

入れ物と中身が中間テーブルを介して紐付いています（1対N）。
さらに、中間テーブルとバージョンが紐付いています（1対1）。

これにより、
・箱固有の情報は入れ物テーブルに
・中身固有の情報は中身テーブルに
といった感じで整理できました。

さらに、中間テーブルとバージョンが紐付いているため、
とあるバージョンでは箱Aの中身がイチゴとブドウの2つ、
となっても管理できます。

某社内ツールでは

某社内ツールでは、

入れ物→商品
中身→実ファイルのファイル名等
バージョン→そのまま

のような形のテーブル構成になっています。
（実際には期間はスケジュールテーブルに切り出して管理してたりなど、微妙に違いますが…）

入れ物ID / 中身ID / ファイル名.拡張子

のように対応させてます。

・オブジェクト設計（クラス図）とマッピングしやすい構成。
・全てLaravelのEloquentで処理できるように。

「バージョンによって使用するファイルが違う」
という関係性を綺麗に表せていて、
今ではしっくりきています。

パフォーマンスを優先するシステムであれば、
もっと違う形の設計になるのかなーと思います。