sql - 世界のすべての住所に共通の番地データベース設計はありますか?

Question

私はプログラマーであり、世界の番地構造をデータベースに格納するための実用的なアプローチが必要です。では、番地を格納するための最適で一般的なデータベース設計はどれでしょうか? 使いやすく、クエリが高速で、世界中のすべての住所を動的に保存できる必要があります。

score 136 · Accepted Answer

標準的な一連のフィールドで、さまざまな国の住所を表すことができます。名前付きまたは番号付きの建物が位置する名前付きのアクセスルート (大通り) の基本的な考え方は、中国を除いてかなり標準的です。その他のほぼ普遍的な概念には次のようなものがあります。集落 (市/町/村) に名前を付ける。地域に名前を付け、英数字の郵便番号を割り当てます。郵便番号とも呼ばれる郵便番号は、一部の国でのみ純粋な数値であることに注意してください。本当にジェネリックにしたい場合は、多くのフィールドが必要になります。

Universal Postal Union (UPU) は、多くの国の住所データを標準形式で提供しています。UPU 形式は、国全体のすべての住所 (使用可能なフィールド精度まで) を保持することに注意してください。したがって、これはリレーショナルです。可能なすべての住所のごく一部のみが保存される顧客住所を保存する場合は、すべてのフィールドと行ごとに 1 つの住所を含む単一のテーブル (またはフラット形式) を使用することをお勧めします。

アドレスを格納する適切な形式は次のとおりです。

住所 1 ～ 4 行目
地域性
領域
郵便番号 (または郵便番号)
国

住所行 1 ～ 4 には、次のようなコンポーネントを保持できます。

建物
サブビル
地番（番地）
前提範囲
大通り
準大通り
二重依存の局所性
サブローカリティ

多くの場合、アドレス行は 3 行しか使用されませんが、これでは不十分な場合がよくあります。もちろん、正式な形式ですべてのアドレスを表すためにさらに多くの行を必要とすることは可能ですが、コンマは常に行区切りとして使用できます。つまり、情報を取得することができます。

通常、データの分析は地域、地域、郵便番号、および国ごとに実行され、ユーザーがデータを入力するときにこれらの要素を理解するのは非常に簡単です。これが、これらの要素を個別のフィールドとして保存する必要がある理由です。ただし、ユーザーに郵便番号や地域の入力を強制しないでください。ローカルで使用されていない可能性があります。

地域性、特に地図の地域性と郵便の地域性の区別が不明瞭な場合があります。郵便局は、近くの大きな町である場合がある郵便局によって見なされるものです。ただし、郵便番号は通常、問題や不一致を解決し、公式の郵便番号が使用されていない場合でも正しい配送を可能にします。

score 49 · Accepted Answer

Database Answersをご覧ください。具体的には、これは多くのケースをカバーしています:

(すべて可変長文字データ型)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

score 27 · Accepted Answer

このデータを保存する主な目的は何ですか? そのアドレスの人に実際にメールを送るつもりですか？人口統計、人口を追跡しますか? 基本的な認証/検証の一環として、発信者に正しい住所を尋ねることができますか? 上記のすべて？上記のどれでもない？

実際のニーズに応じて、a) あまり重要ではなく、フリーテキストアプローチを使用できるか、b) すべての国に対応する構造化された/特定のフィールド、または c) 国固有のアーキテクチャのいずれかを決定します。

score 10 · Accepted Answer

国際住所の場合、情報がフィールドに分割されている場合、情報をフォーマットする方法を見つけるのは非常に困難です。たとえば、イタリアの住所では次のように使用されます。

<street address>
<zip> <town> <region>
<country>

そのような

Via Eroi della Repubblica
89861 Tropea VV
Italy

これは、2 行目の米国住所の順序とはかなり異なります。

SO の質問も参照してください。

タグ「郵便番号」もチェックしてください。

編集：地域と町の逆順 - UPUごと

score 5 · Accepted Answer

多分これは役に立ちます: https://gist.github.com/259744 プロジェクトのために、ISOコード、トップレベルドメイン、電話コード、車のサイン、長さ、正規表現を含む、世界のすべての国に関する情報のテーブルを収集しましたジップ。残念ながら国の名前とコメントはドイツ語のみです...

score 3 · Accepted Answer

ここでの他の答えとは異なり、構造化された住所データベースを持つことは可能だと思います。

帽子をかぶっただけで、私は次の構造を考えることができます：

国
地域（州/州）
地域（市/市町村）
サブローカリティ（郡/ローカリティの他のサブディビジョン）
街

しかし、それを十分に速く照会する方法は？

私がいつもそれを達成できると思う一つの方法は、国ごとに異なりますが、国内ではしっかりしている郵便番号（または郵便番号）を尋ねることです。

このようにして、世界中の郵便局から提供された情報に基づいてデータを構成できます。

score 2 · Accepted Answer

Universal DataModelで有名なLenSilverstonは、単純な派生物または国ごとの派生物のGEOGRAPHIC BOUNDARIESいずれかを受け入れることができる自由形式性の程度に応じて、別の階層を推奨しています。STREET ADDRESS LINE

score 2 · Accepted Answer

いいえ、標準のアドレス指定スキームはありません。通常、国によって異なります。ユニバーサルポスタルユニオンでさえ、Adressing the world について、誰にとってもアドレスは存在しないと述べています。これに対する最善の解決策は、 ISO 3166として知られる 2/3 文字の国コード標準を使用し、それ以外はすべて国の標準に従って処理することです。

ただし、プロジェクトで簡単にアクセスできるツールをどうしても使用したい場合は、Google Place APIを試すことができます。

score 2 · Accepted Answer

いいえ、絶対に違います。米国と日本の住所の仕組みを比較すると、それが不可能であることがわかります。

アップデート：

よく考えてみると、何でもできますが、トレードオフがあります。

1 つのアプローチは、address テーブルと address_attribute テーブルを使用して問題をモデル化することです。それらの間に 1:m の関係があり、何でもモデル化できます。address_attribute テーブルには、pk、名前、値、およびアドレスの親の pk を指す fk があります。これは、名前と値のペアで Map を使用するようなものです。

トレードオフは、アドレスが必要になるたびに JOIN を実行する必要があることです。また、毎回何を扱っているかを把握するために、address_attributes の名前を調べる必要があります。

もう 1 つのアプローチは、住所が世界中でどのようにモデル化されているかについて、より包括的な調査を行うことです。オブジェクト指向の世界では、西側の Address クラス (street1/street2/city/state/zip) と、住所空間をタイル化するのに必要な数の日本、中国のその他のクラスがある場合があります。次に、マスター Address テーブルと子テーブルを他の型に 1 対 1 の関係で関連付けます。

AmazonまたはeBayはどのようにそれを行いますか? 彼らは国際的に出荷します。ロケール固有の UI 機能はありますか? 私は米国のロケールのみを使用しました。

score 2 · Accepted Answer

フィールドを使用する準備ができているかどうかは、自由形式に依存します。自由形式の住所フィールドは 1 つでも構いませんが、地域を絞り込むにはほとんど役に立ちません。

問題は、国によって地理的階層のレベルが大きく異なることです。一部の国では、どこにでも「番地」さえありません。

あまり巧妙にしようとしないことをお勧めします。

score 1 · Accepted Answer

デザインは目的に大きく依存する必要があります。一部の人々は、データを構造化する方法を投稿しています。したがって、単純に誰かに S メールを送信したい場合は、それで十分です。このデータをナビゲーションに使用する場合、事態は複雑になります。カーナビゲーションでは、交通情報 (一方通行など) を格納するための追加の構造が必要になりますが、フットナビゲーションでは、さらに多くのデータが必要になります。ここに小さな例があります。私の街では、私の近所は公園の近くにあります。公園の隣には、かつての飛行場 (実際、ヨーロッパで最も古い飛行場の 1 つ) が航空博物館になっています。航空博物館の隣にはビジネスパークがあります。博物館の番地は 39、ビジネスパークの番地は 39A から始まります。したがって、39 と 39A は近いように見えるかもしれませんが、一方から他方へ歩くには約 1 マイルかかります (車で行く場合はさらに長くなります)。
これは私の街の小さな例にすぎません。おそらく多くの例外を見つけることができると思います (特に、すべての国の田舎や荒野では)。

sql - 世界のすべての住所に共通の番地データベース設計はありますか?

12 に答える 12

Related

Reference