1

物の価格をさまざまな場所に保存するデータベース アプリがあります。各価格には、次のデータが関連付けられています。

  • 価格
  • 日にち
  • 製品番号
  • 国
  • 価格タイプ (工場/卸売/小売)

最後の 3 つの項目 (pID、country、pricetype) は、価格の目的を説明する 1 つの複合項目と考えることができます。このデータには多くの冗長性があります。だから私は考えています：それらを独自のテーブルに分けて、スペースを節約し、クエリを簡素化します。

Normal:
Prices (price_id, price, date, product_id, country_id, pricetype_id)

vs:
Prices (price_id, price, date, descriptor_id)
Descriptors (descriptor_id, product_id, country_id, pricetype_id)

これは、必要なプログラミング作業を追加する価値がありますか? 長期的には多かれ少なかれ拡張可能/保守可能ですか?

4

2 に答える 2

1

これは、必要なプログラミング作業を追加する価値がありますか?

はい

長期的には多かれ少なかれ拡張可能/保守可能ですか?

より拡張性が高く、保守が容易です。

一般
に、常に少なくとも 3NF に正規化する必要があります。

この記事を参照してください: http://databases.about.com/od/specificproducts/a/normalization.htm

于 2011-10-04T11:22:40.287 に答える
-1

そのテーブルで期待するデータの量によって異なります。パフォーマンスやストレージに問題がない場合は、別のテーブルは必要ありません (パフォーマンス上の理由から)。

一方で、冗長性に伴うすべての欠点が発生します。データの不整合などをチェックする必要があります。

ただし、選択したデザインに関係なく、現在の道を変更する時間はまだあります。

于 2011-10-04T11:23:49.833 に答える