地理的な住所/場所をデータベースに保存する一般的な方法は何ですか？[閉まっている]

地球上の住所に適した地理的な住所/場所の正しい形式は何ですか？今のところ：

• 国
• シティ
• 通り
• 数
• テキストデータ（簡単にするため）
• zip
• 緯度/経度

しかし、私はそれを改善できると信じています。国の州/地域または地域のようなものがあるかもしれません。または、シンガポールや香港には、地域/地域/州はありません。

通りはないかもしれませんが、道路や大通りなどがあります。多数の建物が複合している場合があります。床があるかもしれません。部屋番号。等....

Googleは、世界中のすべての国の郵便住所の検証に役立つライブラリを開発しました。このライブラリを使用して、このデータを保存するスキーマを設計できます。

ターゲットとする顧客ベースのアドレス全体で最も一般的な必須フィールドを探して開始し、さまざまな要件を持つ国を特定したら、引き続きスキーマを調整できます。

地理的な住所/場所をデータベースに保存する一般的な方法は次のとおりです。

[Address] nvarchar(max) not null

これにより、最小限のプログラミングコードが必要になり（したがって、メンテナンスコストが削減されます）、あらゆるアドレスと完全に互換性があります。ただし、次の3つの大きな問題があります。

• データ検証の欠如は、住所を保存する以外の目的でフィールドを使用できることを意味します。目的の1つは、アドレスフィールドに2 GBのデータを入力して、データベースのスペースを埋めることを目的としたDOS攻撃です。

• この方法で保存されたデータは、ビジネスインテリジェンスおよびデータマイニングの目的で処理することを不可能にします。たとえば、インドから何人のユーザーがいますか？これらのアドレスは正規化されないため、わかりやすい方法はありません。

• ユーザーは、誤って不完全なアドレスまたは明らかに間違ったアドレスを入力する場合があります。

最初の問題を軽減するために、フィールドを合理的な制限と思われるものに制限します。個人的には、1000文字から始めて、十分な大きさのデータセットを取得したら、最初のユーザーが入力したアドレスの長さに基づいて文字数を減らします。

他の2つの問題を軽減するために、住所を解析し、国、都市、郵便番号などを含むデータを表示するサードパーティAPIを使用できます。可能であれば、APIは住所を表示できる必要があります不完全な住所や間違った住所を入力するリスクを軽減するために、ユーザーにマップを戻します。ほとんどのユーザーは自分の住んでいる場所を知っており、マップ上の別の位置を見るとすぐに入力を確認する手がかりが得られます。

どんなAPIを使用しても、完璧ではないことに注意してください。ほとんどのアドレスが検索されますが、すべてではありません。これは、アドレスが存在しないことをAPIが示しているが、ユーザーが存在すると主張している場合、たとえユーザーが間違っていても、ユーザーをアプリオリに信頼する必要があることを意味します。

これは、元のユーザーの入力をAPIの結果と並べて保存する必要があることも意味します。これは、スキーマが次のようになることを意味します。

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

ありません。

国ごとに異なる住所形式があります。あなたが幸運であり、彼らがまったくフォーマットを持っているなら！

明らかに、緯度/経度は地球上のポイントを提供しますが、個々の家を識別するのにはあまり役に立ちません。たとえば、タワーブロックを考えてみてください。

最善の策は、各国の郵便サービスで正式な形式を確認することです。これはバックエンドデータベースに最適です。ただし、ほとんどの人が慣れているよりもはるかに多くのフィールドが含まれるため、エンドユーザー向けに単純化する必要があります。

たとえば、英国には「二重依存地域」などが含まれていますが、尋ねるとそれが何を意味するのか誰もわかりません。

唯一の普遍的な形式は、複数のテキスト行を持つ単一のテキストフィールドを持つことです。これにより、地球上のあらゆるアドレスが許可されます。

私は多くの国で使用されるソフトウェアソリューションを開発しています。この問題に対処するには、最初に大きなエンティティから開始します。つまり、国には最小のフィールドまたは最小のフィールドがあります。これは、これまでに実験したすべての国でうまく機能します。また、スマートな重複防止システムもあり、ユーザーが非常に「創造的」であるために何らかの形でシステムに参加している人々の合併もあります。管理セクションには、国ごとの住所フィールドの順序設定があります。つまり、日本では郵便番号が最初にあり、英国/米国は最後です。

一般的に、次を使用します。

• 国
• 郵便番号
• 州/県/県/郡
• 市/町/村
• 通り/道路/ブロック
• 建物名/番号
• 特定/カスタム情報

入力して保存すると、共役バージョンを表示でき、フィールドは不要です。

私が言ったように、これは私たちがソフトウェアを持っているすべての国で機能し、1989年以来の開発の結果です。

これが何らかの形で役立つか、少なくとも別の洞察を提供することを願っています。

すでに述べたように、最も普遍的な（ただし、検証するのは実用的ではなく、おそらく最も有用ではない）単一の大きなUnicodeフィールドです。

国を住所の残りの部分から分離し、ISO国コードとして保存できます。国を正規化し、住所の残りの部分を検証する際に何らかの有用性を提供します。

郵便番号（郵便番号）をその他の住所から分離することもできます。これは、住所の残りの部分を検証するのにも有用であり、ジオロケーションでは（不正確ではありますが）役立つ可能性があります。たとえば、カナダでは、郵便番号と番地（別名家屋番号）のみを指定して住所を一意に識別できます。これはすべての国で当てはまるわけではありません。

各国が住所を作成する方法が異なるため、フィールドを州/県または都市専用にすることは、より困難になり始めます。最初のオーディエンスは北米に焦点を当てているため、このようなフィールドを持つアドレステーブルを設定しました。これは、国際的なオーディエンスが問題を引き起こす可能性があることを知っているためです。厄介で潜在的に障害が発生しやすい妥協-決して一般的ではありません。

Mitchdavの答えに反して、Googleのライブラリを使用することはお勧めしません。ユニットテストデータを見つけることを期待して、非正統的なアドレス指定スキームを使用して、さまざまな国際的な場所のリポジトリを検索しましたが、心配なことにリポジトリ全体でゼロヒットが見つかりました。

あなたの最善の策は、住所を自由形式の複数行テキストとして扱うことだと思います。すべてのアドレスを検証できない可能性がありますが、一部のアドレス形式は非常に奇妙で予想外であり、最終的に正しいアドレスを入力する責任はユーザーにあり、ほとんどのアプリケーションではユーザーが無効なアドレス。

おそらく、バリデーターを使用して警告を提供するかもしれませんが、それ以上のものはありません。ただし、検証しないアドレスは拒否しないでください。拒否すると、一部の顧客が失われる可能性があります。これは、ユーザーが奇妙なアドレス形式のエリアに住んでいる場合、警告を無視しても安全であることを伝えるように、ユーザーに警告を伝える方法の問題につながります...

あなたが地球上の任意のアドレスを言うように、唯一の緯度経度または...があります

https://what3words.com

3つの言葉は、アルゴリズムであり（データベースではないため、あらゆるものに埋め込むことができます）、地球上のどこでも3x3メートルのパッチを定義できます。

トンガと他のいくつかの州は、それを郵便番号システムとして採用していますが、オーバーレイとしてそれを置き換えることはありませんが、かなりクールで、非常によく構築され、考え抜かれています。