13

重複の可能性：
世界のすべての住所に共通の番地データベース設計はありますか？
国際住所をデータベースに保存するための「最良の」方法は何ですか？
データベース内の一貫性のある包括的なアドレスストレージのベストプラクティス

現在、Customers、Contacts、Facilities、Clientsの4つのテーブルがあります。

これらの各テーブルには、AddressLine1、AddressLine2、City、StateOrProvince、PostalCodeの各フィールドがあります。

アドレスを別のテーブルに移動し、アドレスのタイプ（請求、配送、メインなど）も指定できるようにしたいと思います。

私の解決策は次のとおりです。

  1. AddressLine1、AddressLine2、City、StateOrProvince、PostalCodeを顧客、連絡先、施設、およびクライアントから削除します。
  2. フィールドAddressID（PK）、AddressLine1、AddressLine2、City、StateOrProvince、PostalCode、LastUpdateUser、LastUpdateTimeを使用してAddressesテーブルを作成します。
  3. フィールドAddressTypeID、AddressTypeName、AddressTypeDescription、AddressTypeActive、LastUpdateUser、LastUpdateTimeを使用してAddressTypesテーブルを作成します
  4. フィールドCustomerID、AddressID、AddressTypeID、CustomerAddressActive、LastUpdateUser、LastUpdateTimeを使用してCustomerAddressesテーブルを作成します
  5. ClientID、AddressID、AddressTypeID、ClientAddressActive、LastUpdateUser、LastUpdateTimeのフィールドを持つClientAddressesテーブルを作成します
  6. ContactID、AddressID、AddressTypeID、ContactAddressActive、LastUpdateUser、LastUpdateTimeのフィールドを持つContactAddressesテーブルを作成します
  7. フィールドFacilityID、AddressID、AddressTypeID、FacilityAddressActive、LastUpdateUser、LastUpdateTimeを含むFacilityAddressesテーブルを作成します

私が考案したものよりも良い解決策があるかどうかを判断するためのガイダンスを探しています。なぜ誰もが考えるのですか？

編集：私はこの時点で米国外では何も気にせず、番地を保存する方法、つまり番地と番地全体の関係も気にしません。私はデータベース設計とテーブル構造の観点から懸念しています。

4

4 に答える 4

13

私が以前働いていたDBAはこの宝石を教えてくれました、そしてそれは私たちにとって素晴らしい働きをしました（最初の2つのステップはあなたのソリューションと同じです）：

  1. AddressLine1、AddressLine2、City、StateOrProvince、PostalCodeを顧客、連絡先、施設、およびクライアントから削除します。
  2. フィールドAddressTypeID、AddressTypeName、AddressTypeDescription、AddressTypeActive、LastUpdateUser、LastUpdateTimeを使用してAddressTypesテーブルを作成します
  3. フィールドAddressID（PK）、AddressTypeID（FK）、AddressLine1、AddressLine2、City、StateOrProvince、PostalCode、LastUpdateUser、LastUpdateTime、CustomerID（FK）、ClientID（FK）、ContactID（FK）、FacilityID（FK）を使用してAddressesテーブルを作成します
  4. アドレステーブルで、CustomerID、ClientID、ContactID、またはFacilityIDの外部キーの1つだけが一度に非NULLになるように制約を設定します。

このようにして、すべてのアドレスを1つのテーブルにまとめ、必要なレコードを参照でき、参照整合性は損なわれず、中間テーブルにトラバースする必要がありません。

欠点は、オブジェクトの新しいクラス（たとえば、Employeeテーブル）にアドレスを追加する場合、AddressesテーブルにEmployeeID列を追加する必要があることですが、これは非常に簡単です。

于 2009-09-18T16:50:52.727 に答える
2

私たちのデータベースにあなたが考慮したいと思うかもしれないもう一つのことは、アドレステーブルに通信フラグを持ち、1人あたり1つのアドレスだけが通信として賭けることができるようにするトリガーを付けることです。私たちはデータベース内の人々に大量のメールを送信し、その人の3つのアドレスのどれが、メールを送信するときに使用する必要があるアドレスであるかを知ることは非常に貴重です。また、一部のレポートで1人あたり複数のレコードを取得しないように、1人あたり1つのアドレスのみを取得するようにクエリを実行する場合も簡単になります。

于 2009-09-18T17:06:01.427 に答える
0

また、簡単にするために、アドレス情報をテーブルに展開するビューを作成することももう1つ追加したいと思います。そうしないと、この方法でdbを設計するのが嫌になる可能性があります。

于 2009-09-18T16:10:48.840 に答える
0

単一のAddressLink（名前？）テーブルを検討します

LinkTypeID (Customer,Client,Contact,Facility) -- needs additional TypeID table
ID (CustomerID,ClientID...)
AddressID
AddressTypeID
AddressActive
LastUpdateUser
LastUpdateTime

新しいアドレスリンクタイプを追加するということは、新しい[TypeID] Addressesテーブルを含む新しいLinkTypeIDを追加することを意味し、クエリを変更する必要はありません。アドレスのすべての用途（削除など）を探している場合は、見る。

とにかく、これは私たちのやり方とかなり似ています。

ああ、いくつかの奇妙な外れ値の状況のた​​めに、Addresses（同等の）テーブルにAddressLine3があります。

于 2009-09-18T16:23:19.390 に答える