ユーザーが注文できるデータベースでは、住所を含む新しいテーブルを作成するのと、各注文のヘッダーに住所データを含めるのとのどちらがよいでしょうか。
質問する
594 次
4 に答える
5
これは、ユーザー（およびその住所）だけでなく、販売している製品の価格やその他の情報についても説明します。これらの情報は、注文後に変更される可能性がありますが、注文自体はそのままにしておく必要があります。
一般に、これには2つのアプローチがあります。
- 注文（およびそのアイテム）で必要なものをすべてコピーします。「マスター」データが変更された場合でも、使用できるオーダー内にコピーがあります。
- これと同様に、データベース全体を「バージョン管理」または「履歴化」します。
（1）はより「実用的な」アプローチですが、データの冗長性につながる可能性があります（たとえば、アドレスが変更されない場合でも、別のコピーを作成することになります）。
（2）はより「純粋な」アプローチですが、より多くのJOINを必要とし、一般により複雑になる可能性があります。
于 2012-08-13T08:18:02.903 に答える
5
一般に、分離する可能性が最も高いでしょう。
- ユーザー
- 住所
- 注文情報
これは、ユーザーが時間の経過とともにアドレスを変更できるためですが、古いアドレスは、それらに対する注文があるため保持する必要があるためです。さらに、1 人のユーザーが同じアドレスから複数の注文を行うことができるため、この情報を分離して重複を減らします。
于 2012-08-13T01:04:49.007 に答える
0
住所が注文と同じテーブルにある理由は考えられませんが、これにより、作業が少し節約されます。
別のテーブルを持つための引数は次のとおりです。
すべての注文を検索しなくても、複数の配送先住所をユーザーに関連付けることができます (そのため、ユーザーが以前に使用した住所のドロップダウン リストを簡単に提供できます)。
重複を避けて、請求先住所と配送先住所に同じ表を使用できます
注文ごとに更新することなく、将来、住所の保存方法を拡張/変更できます (たとえば、海外に行くときに国フィールドを追加するなど)。
これはどれも最適化とはあまり関係ありません。なぜそれがタイトルにあるのかわかりませんか？
[Branko は注文データの保存について良い点を持っています。ただし、データベースを完全にバージョン管理する必要はありません。注文から参照されているもの (ユーザーやアドレスなど) に「期限切れ」フラグを付けることができますが、現在の値はありません。つまり、現在と過去の 2 つの「バージョン」だけが必要です。注文テーブルで明示的に参照を作成する限り (そのため、ユーザーを介して配送先住所に移動するのではなく、注文テーブルから住所テーブルに直接リンクします。これを機能させることができます。データベースの完全なバージョン管理、人間関係を含め、大変な作業です。]
于 2012-08-13T01:03:01.290 に答える