0

果物の種類の名前、価格、ソースを格納する Fruit というテーブルを設計したいと考えています。サンプルデータ：

(Apple, 100c, SuperMarket1)
(Orange, 101c, SuperMarket1)
(Apple, 99c, SuperMarket2)
(Orange, 103c, SuperMarket2)

SuperMarket1 の Orange 価格を公式とし、SuperMarket2 の Apple 価格を公式とします。

現在、ソースはテーブルの主キーではないため、非公式のエントリはすべて表示されません。非公式の価格を保存したい場合は、ソースを主キーの一部にする必要があります。エントリを公式として指定するには、Source=Official を使用して追加のエントリを入力するか、公式として指定された列を作成する必要がありますか?

私の目標は次のとおりです。

  1. 1 つのテーブルに格納する必要はなく、利用可能なすべての価格を格納できます。
  2. 公式エントリのソースは簡単に識別できる必要があります。
  3. 最小限の参加数で公式を照会する機能。
  4. 果物の種類に対して複数の公定価格を設定することはできません。
  5. 果物のセットは小さくなく (果物は単なる例です)、進化しています。タイプごとに公式のソースを格納するための追加のテーブルを維持することは、今後大きな負担になる可能性があります。

すっきりとしたデザインのアイデアはありますか？

4

1 に答える 1

1

次のようなものが必要になるようです。

ここに画像の説明を入力

注: 上記のモデルでは、FRUIT.STORE_ID は NULL 可能であり、FK サイクルを中断し、実行時に新しいデータを実際に挿入できるようにします。DBMS が遅延制約をサポートしている場合、このフィールドを NOT NULL にすることができます (実際に公式価格なしで果物を許可したい場合を除く)。

1) 利用可能なすべての価格を 1 つのテーブルに保存する必要はありません。

このモデルでは、価格は果物ごとではなく、店舗ごとの果物ごとです。

2) 公式エントリのソースは簡単に識別できる必要があります。

これが FRUIT.STORE_ID の目的です。

3) 最小限の参加数で公式を照会する機能。

SELECT * FROM FRUIT JOIN PRICE
    ON FRUIT.FRUIT_ID = PRICE.FRUIT_ID AND FRUIT.STORE_ID = PRICE.STORE_ID

4) 果物の種類に対して複数の公定価格を設定することはできません。

各果物は FRUIT の 1 つの行で表され、FRUIT.STORE_ID は行ごとに複数の値を格納できません。

5) 果物のセットは小さくなく (果物は単なる例です)、進化しています。タイプごとに公式のソースを格納するための追加のテーブルを維持することは、今後大きな負担になる可能性があります。

幸いなことに、データベースは大量のデータを維持するのに非常に優れています。

于 2012-06-29T22:46:22.793 に答える