27

これはいいデザインなのかしら。住所情報（たとえば、番地、郵便番号/郵便番号、国、ファックス、電子メール）を必要とするテーブルがいくつかあります。同じアドレスが複数回繰り返される場合があります。たとえば、住所がサプライヤに対して保存され、その後、サプライヤに送信される各発注書に保存される場合があります。その後、サプライヤは住所を変更でき、その後の発注書には新しい住所が必要になります。これよりも複雑ですが、これは要件の例です。

オプション1すべてのアドレス列を属性としてさまざまなテーブルに配置します。作成時に、詳細をサプライヤからPOにコピーします。の複数のコピーを保存する可能性があります

オプション2別のアドレステーブルを作成します。サプライヤおよび発注書テーブルからアドレステーブルへの外部キーを用意します。更新は意図した以上に変更される可能性があるため、アドレステーブルでの挿入と削除のみを許可してください。次に、アドレステーブルから、何も参照されなくなった行を削除して、未使用の行が残らないようにするスケジュールされたタスクがあります。おそらく、アドレステーブルのすべての非pk列に一意の制約があり、重複も停止します。

私はオプション2に傾いています。もっと良い方法はありますか？

編集：送信時のアドレスを発注書に残しておく必要があります。また、配送先住所と請求先住所がある可能性があるため、私が提案したのは少し複雑です（住所情報を持つ他のテーブルもたくさんあります）。

しばらくすると、古い発注書を日付に基づいてまとめて削除します。この後、何も参照されなくなったアドレスレコードをガベージコレクションするつもりでした（そうしないと、リークが発生しているように感じます）。

4

7 に答える 7

28

私は実際にこれを面接の質問の1つとして使用しています. 以下は、開始するのに適した場所です。

Addresses
---------
AddressId (PK)
Street1
... (etc)

と

AddressTypes
------------
AddressTypeId
AddressTypeName

と

UserAddresses (substitute "Company", "Account", whatever for Users)
-------------
UserId
AddressTypeId
AddressId

このように、アドレスはそれらがどのように使用されているかをまったく認識せず、エンティティ (ユーザー、アカウント) もアドレスについて何も直接知りません。それはすべて、作成するリンク テーブル次第です (この場合は UserAddresses ですが、モデルに合わせて何でもできます)。

大規模なデータベースになる可能性があるため、やや矛盾したアドバイスの 1 つ: 「HasMoreAddresses」フィールドと共に、「プライマリ」アドレスをエンティティ (この場合は Users テーブル) に直接配置します。上記のクリーンなデザインをそのまま使用する場合と比べると厄介に思えますが、一般的なユース ケースのコーディングを簡素化でき、非正規化によってパフォーマンスが大幅に向上する可能性があります。

于 2008-11-20T22:28:21.080 に答える
7

オプション 2、間違いありません。

留意すべき重要事項: アドレスが相互にリンクされている場合にユーザーに示すことは、設計の重要な側面です。つまり、会社の住所は配送先住所と同じです。配送先住所を変更したい場合、会社の住所も変更したいですか、それとも新しい荷積みドックを指定したいですか? この種のもの、およびこの情報をユーザーに提示し、この種の粒度で物事を変更する機能は非常に重要です. これは、更新についても重要です。ユーザーにエントリを「分割」する粒度を与えます。この種の UI は簡単に設計できるわけではありません。実際のところ、それは雌犬です。しかし、実行することは非常に重要です。それ以下だと、ほぼ間違いなく、ユーザーは非常にイライラしたりイライラしたりします。

また; 古い住所データを保持することを強くお勧めします。クリーンアップするプロセスを実行しないでください。非常にビジーなデータベースがない限り、データベース ソフトウェアは余分なデータを処理できます。本当。データベースに関して私が目にするよくある間違いの 1 つは、過剰な最適化を試みることです。クエリを徹底的に最適化したいのですが、未使用のデータを最適化したくありません。(繰り返しますが、データベースのアクティビティが非常に高い場合は、これを行う必要があるかもしれませんが、データベースがテーブルに余分なデータが残っていても問題なく動作することはほぼ確実です。) ほとんどの状況では、実際にはより有利です。データベースを最適化しようとするよりも、単純にデータベースを大きくすることをお勧めします。(テーブルから散発的なデータを削除しても、データベースのサイズが大幅に縮小されることはありません。

于 2008-11-20T22:28:57.180 に答える
2

注文書に最初に記載されていた住所の履歴を残しておきたいですか?

はいの場合はオプション 1 を使用し、それ以外の場合はそれをサプライヤ テーブルに保存し、各発注書をサプライヤにリンクします。

ところで: DB 設計が不十分であることの確かな兆候は、データを「クリーンアップ」または同期させるために自動化されたジョブが必要なことです。その点では、オプション 2 はおそらく悪い考えです。

于 2008-11-20T22:11:57.057 に答える
2

私はJohnFxに同意すると思います..

(カタツムリ) メール アドレスについてのもう 1 つの点は、国を含めたいので、国際的に発送/郵送したいと考えているため、住所フィールドはほとんど自由形式のテキストのままにしてください。ノルウェーには郵便番号がなく、4 桁の郵便番号があるのに、5 桁の郵便番号を作成しなければならないのは本当に面倒です。

最適なフィールドは次のとおりです。

  • 名前/会社
  • 住所 (複数行テキストエリア)
  • 国

米国の郵便システムで特定の形式の郵便番号が必要な場合は、これも含めますが、米国が国として選択されていない限りオプションにします。誰もが自分の国で住所をフォーマットする方法を知っているので、改行を保持している限り問題ありません...

于 2008-11-20T22:28:22.203 に答える
1

アドレス テーブルの行が未使用になるのはなぜですか? 確かに、それらを使用した注文書によってまだ指摘されているでしょうか?

重複を停止することが優先事項であるため、クリーンアップの必要がないように思えます。

于 2008-11-20T22:27:48.943 に答える
0

オプション1を使用しているすべてのシステムがデータ品質の問題に陥るのを見てきました。5年後、すべてのアドレスの30％が最新ではなくなります。

于 2009-02-03T18:24:14.983 に答える
0

注文の場合、注文が送信された場合に個人 (または会社) の住所が変更されるため、住所を更新する必要はありません。注文に問題がある場合は、注文が実際に送信された場所の記録を確認してください。

アドレステーブルは良い考えです。同じエンティティが重複したアドレスを持つことができないように、一意の制約を作成します。ユーザーがそれらを検索する代わりに別のものを追加する可能性があるため、それらを取得する可能性があり、綴りが少し異なる場合 (Street ではなく St.)、一意の制約はそれを妨げません。オーダー作成時のデータをオーダーにコピーします。これは、何をどこに送信したかの履歴レコードが必要なため、複数のレコードが必要なケースの 1 つです。テーブルへの挿入と削除のみを許可することは、更新よりも安全ではなく、データベースの作業が増えるため、私には意味がありません。更新は、データベースへの 1 回の呼び出しで行われます。アイデアのアドレスが変更された場合は、まず古いアドレスを削除してから、新しいアドレスを挿入する必要があります。

于 2008-11-20T22:29:02.920 に答える