米国の住所の正規化（住所、郡、市、州、郵便番号）？
私は過去数年間、アドレスを格納するのに適した方法を理解しようと努めてきました。私は「ずっとノーマライズする」だけでなく、「できる限りノーマライズする」こともしているので、自分のプロジェクトに何が良いのかを判断するのに頭が足りません。
まもなく、私のプロジェクトには多数のユーザー（10万人以上）が関与し、すべてのユーザーに1〜3のアドレス（個人、ビジネス、請求）が保存されます。つまり、100k + * 3つのアドレスのレコードを持つことができます。また、私は郵便番号による多数の検索を行います（郵便番号に登録されたアドレスを持つユーザーを取得します）。私は米国の住所しか持っていません。
ユーザーとアドレスのテーブルと、プロジェクトでのそれらの関係に満足しています。ただし、関係のないテーブルは、私を混乱させるものです。
（画像に表示されている私のテーブルは、私が必要なものとその方法をよりよく理解するためだけのものです。冗長なフィールドがたくさんあるので、そのままにしないでください。）
これをどのように設計すべきかについて誰かが何かヒントを持っていますか？
誰かが大企業が使用しているスキーマ（UPS、USPSなど）のスキーマまたは同様のスキーマへのリンクまたは何かを持っていますか？
@datagodの答えは良いと思いますが、あなたの指定された要件に基づいて少し調整します：
アドレステーブル
AddressLine1 varchar(255) -- If using SQL Server I would go with NVARCHAR instead. You don't seem to need unicode support but why not support it since things will often be converted to unicode in the application layer by default anyway, and storage is cheap.
AddressLine2 varchar(255)
City varchar(50)
ZipCodeID int -- FK to PostalCode table
County varchar(50)
State varchar(50)
ご覧のとおり、私の推奨事項は@datagodのものと非常によく似ています。私は2つのことを変更しました：
CountryFKを削除しました。あなたは米国の住所だけが必要だと言っていたからです。ZipCode/PostalCodeをFKにしました。これにより、郵便番号をより効率的に索引付け/照会できるようになると思います。
さらに、データ検証の目的でそのリストを使用したい場合を除き、郵便番号の外部マスターリストをアップロードする必要はないように思います...アドレスが挿入されたときにその郵便番号が存在するかどうかを確認して、郵便番号表が存在しない場合。これは挿入にいくらかのオーバーヘッドを追加しますが、一般的な郵便番号がかなり迅速に挿入されるので、それほど多くはないと思います。
海外に移動する場合は、@ datagodの提案に従ってCountryテーブルを追加します。
次のいずれかが当てはまらない限り、データベースをcites/counties/streetsなどに正規化することは、現時点ではやり過ぎのようです。
- これらのデータポイントで頻繁にクエリを実行していて、インデックス/正規化の恩恵を受ける
- ある種の地域ベースのセキュリティを実行する必要があります。つまり、アトランタにあるセールスは、これら3つの郡の外の情報にアクセスできません。
- これらのリストをデータ検証として使用して、他のユーザーが悪いデータを提供していないことを確認します。 （これは、データを検証する距離によっては、実装が面倒になるようです。）
- 私がそれを考えていなかった他のいくつかの理由は、あなたの人生をより簡単にするために、さらに正規化をします。
私は何百万もの住所レコードで@datagodの経験がないので、私のアドバイスは明らかに間違っているかもしれませんが、それは私が取るアプローチです。
編集： 2つの答えがZipコードの正規化を避けているので、これまでに経験したことがないため、問題点を見落としている可能性があります。
私は何百万もの既存の国際住所を扱います。次のデザインは私のプロジェクトで機能します：
アドレステーブル
AddressLine1 varchar(255)
AddressLine2 varchar(255)
City varchar(50)
PostalCode varchar(20)
State varchar(50)
CountryID int (FK to Country table)
頻繁に更新されるマスターリストが本当にない限り、郵便番号と州を正規化する誘惑を避けてください。
国は管理が容易であるため、独自のルックアップテーブルに属しています。 マスターリスト はオンラインで簡単に見つけることができます。
しばらくして郵便番号を正規化しようとしましたが、1つの都市に複数の郵便番号が存在する可能性があるため、実際には機能しません。したがって、CityとStateを正規化できますが、郵便番号をテーブルに追加するだけです。
1のようなテーブルがあるように、city + zipcodeで正規化できると思います。 「インディアナポリス46422」、および2 |その中の「インディアナポリス46421」。
ただし、注意しなければならないのは、費用対利益です。信じてください、私は私の店の3NFデータベースの大きなこだわりですが、都市と郵便番号に基づいて正規化することは非常に面倒で、コストを上回る利益を得ることができません。
価値のあるものとして、USPSには、この国の住所を明確にし、確認するために使用できるデータベースがあります-どの郵便番号がどの州のどの町をどの道路（およびどの住所）が各郵便番号内に存在するかを網羅しています住所が道路のどちら側にあり、どのブロック内にあるか、そして今日ではおそらく緯度/経度の近似値です。これらは、企業が郵送先住所を確認するために使用するデータベースであり、自動車のGPSユニットなどのマッピングシステムが住所の実際の場所を特定するために使用する情報の一部です。
このデータが無料で入手できるかどうか、または購入して更新するために料金がかかるかどうかはわかりません。私がこれを最後に見たとき、彼らはまだそれをテープで郵送していました、そして明らかに経済は今非常に異なっています。それでもそれは不当に高価ではありませんでした。 USPSは、文字化けしたアドレスに送信されたものを実際に処理することを望まない。
質問を正しく理解するのが難しい理由についてのコメントがあるので、これはあまり答えではありません。私はオーストラリアにいることに注意してください。住所は似ていますが、まったく同じではありません。
データベースの鍵は、それが情報ではなくデータを表すことです。これははるかに複雑です。データは単純なルールに従っており、必ずしも実際の生活を反映しているわけではありません。
たとえば、町、州、郵便番号を考えてみましょう。州は独特ですが、町はそうではありません。郵便番号はその問題を解決することになっていますが、少なくともオーストラリアでは、複数の町が同じ郵便番号を持つことがあり、1つの町が複数の郵便番号を持つこともあります。そして、時々、町は隣接する州の範囲からの郵便番号を持つことができます。
つまり、各町は実際には町/州/郵便番号の組み合わせの一部です。郵便局にはそれらの間の関係のある種の概念がありますが、それはそれほど厳密なものではなく、多くの（部分的な）例外があります。
このため、町を別の表として表し、町、州、郵便番号を個別のデータ列と見なし、正規化を妨げるそれらの間の関係を見落とすのが最善だと思います。
組み合わせは主キーと見なすことができますが、私は常に個別の主キーを好み、残りの組み合わせから一意のキーを作成します。
ここでは郡を使用していないため、郡がどこに入るのかわかりません。