仕様表を参照可能にすべきでしょうか?

Question

ここにはデータベースコアの専門家がたくさんいると思うので、stackoverflow でこの質問をすることにしました。

私は Web サイトを開発しています。その主な関心は、デジタル カメラ、プリンター、冷蔵庫など、現実世界で入手可能なすべての製品のインデックスを作成することです。ご存知のとおり、各製品には独自の仕様があります。たとえば、デジタルカメラには重さ、レンズ、シャッタースピードなどがあります。各仕様にはタイプがあります。たとえば、価格（私はスペックのように捉えています）は数値です。

最も標準的な方法は、指定された製品に必要な仕様を適切なタイプで作成し、それを製品に割り当てることだと思います。したがって、個別の製品ごとに PRICE を作成し、それにタイプ番号を設定する必要があります。

それで、ここに私の質問があります。すべての仕様を含む仕様のテーブルを作成することは可能ですか。たとえば、数値タイプの PRICE が以前に作成されており、テーブル内で価格を検索して製品に割り当てるだけで済みます。この方法の問題は、ユーザーが重複したエントリを作成するのを防ぐ良い方法が見つからないことです。彼は必要な仕様 (以前に追加されている場合) を見つけることができなければなりません。また、同じ名前の仕様がいくつかある可能性があるため、彼が見つけた仕様が実際に彼が必要としていたものであることも知ってもらいたいのです。種類も使い方も違う。見つからない場合は、彼が作成します。

何か案は？

- - - - - - - - - - - - - - アップデート - - - - - - - - - - - -------

私の質問はデータベースの柔軟性に関するものではありません。2 番目の方法では、ユーザーがスペック表をめちゃくちゃにしてしまうと思います。彼らは何千もの重複エントリを作成するでしょうし、適切な仕様を見つけることもできないと思います。

Answer 1

要件に基づいて私が提案するデータ モデルは次のとおりです。

SPECIFICATIONS テーブル

• SPECIFICATION_ID, 、PK
• SPECIFICATION_DESCRIPTION

これにより、アイテムに固執することなく、多数の仕様を持たせることができます。

ITEM_SPECIFICATION_XREF テーブル

• ITEM_ID, 、PK、FKへ ITEMS テーブル
• SPECIFICATION_ID, 、PK、FKへ SPECIFICATIONS テーブル
• VALUE, 、PK

利点：

1. 主キーを複合キーにすると、値のセットがテーブル全体で一意になります。幸か不幸か、特定の仕様を持つアイテムの値は 0.99 と 1.00 になる可能性があり、これらは有効です。
2. この設定により、仕様を 0 個以上の項目に関連付けることができます。

Answer 2

たった今回答を終えました 動的テーブル生成同様の問題について説明しています。を見てください。 観察パターン. 。「観察」を「仕様」に、「主題」を「製品」に置き換えると、次のようになります。 このモデル 便利 -- Report テーブルと Rep_mm_Obs テーブルは必要ありません。