私は最近、あなたが説明したものに近い製品に取り組んでいます。そして、あなたの答えは、プロジェクトを実装する意思がある複雑さのレベルに依存すると思います. 最も簡単な方法は、製品情報を請求書レコードに保存することです。しかし、これは時間の経過とともに冗長性につながります。
一方、リビジョン メカニズムを実装して、時間の経過に伴うレコードの変更を追跡できます。これは、レコードに 1 つではなく 2 つの ID を使用することで簡単に実行できます。サンプルテーブルは次のとおりです。
CREATE TABLE IF NOT EXISTS `product` (
`product_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`entity_id` bigint(20) unsigned NOT NULL,
`name` varchar(255) NOT NULL,
`price` double NOT NULL DEFAULT '0',
PRIMARY KEY (`product_id`),
KEY `inx_entity_id` (`entity_id`)
) DEFAULT CHARSET=utf8 ;
はproduct_id
通常の自動インクリメント IDentity_id
ですが、同じ製品のすべてのレコードで同じである特別な ID です。この設計では、レコードを削除したり、更新したりすることはありません。常にテーブルに挿入するだけで、製品のリストを取得する必要がある場合は、以上のグループが適切であることを覚えておく必要がありますentity_id
。製品情報は、最大のレコードで見つけることができますproduct_id
。おそらく、s を追跡するためにエンティティ テーブルを作成する必要があるかもしれませんentity_id
。
この設計は、製品の情報を請求書にコピーするよりも複雑です。しかし、それには非常に多くの大きな利点があります。製品の価格変動を追跡できるように。または、外部キーをproduct_id
使用して製品の 1 つの特定のリビジョンを指すentity_id
か、特定のリビジョンの代わりに を使用して製品タイプを示すことができます。もちろん、その複雑さには費用がかかりますが、それだけの価値があるかどうかを判断できるのはあなたです.