地理的な住所/場所をデータベースに保存する一般的な方法は何ですか？
地球上の任意の住所に適した地理的な住所/場所の正しい形式は何ですか？現時点で私は：
- 国
- 市
- 通り
- 数
- テキストデータ（簡単にするため）
- 郵便番号
- 緯度/経度
しかし、私はそれを改善できると信じています。国の州/地域、または地域のようなものがあるかもしれません。あるいは、シンガポールや香港など、地域/地域/州はありません。
通りはないかもしれませんが、道路または大通りまたは何か他のものがあります。建物の数は複合であるかもしれません。床があるかもしれません。部屋番号。等....
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年以来開発の結果です。
これが何らかの形で役立つか、少なくとも別の洞察が得られることを願っています。
すでに述べたように、最も普遍的な（しかし、検証するのは実用的ではなく、おそらく最も役に立たない）は、単一の大きなユニコードフィールドです。
国を残りの住所から分離し、ISO国コードとして保存できます。それは国を正規化し、住所の残りを検証するのにいくらかの有用性を提供するでしょう。
郵便番号、つまり郵便番号を残りの住所から分離することもできます。これは、住所の残りの部分を検証するのにも有用であり、（正確ではありませんが）ジオロケーションに役立ちます。例：カナダでは、郵便番号と番地（別名家屋番号）のみを指定して住所を一意に識別できます。これはすべての国で当てはまるわけではありません。
各国が住所を作成する方法にはばらつきがあるため、フィールドを州/省または都市専用にすることはさらに問題になります。最初のオーディエンスは北米に集中しているため、このようなフィールドを持つアドレステーブルを設定しました。海外のオーディエンスには問題が発生することがわかっているためです。ほとんどの場合、それらは「靴角」になる可能性がありますが、厄介で潜在的に失敗しやすい妥協-間違いなく普遍的ではありません。
ミッチダブの答えに反して、私はグーグルのライブラリを使用しないことを勧めます。私はリポジトリを検索して、ユニットテストデータを見つけることを期待して、非標準的なアドレッシングスキームでさまざまな国際的な場所を探しましたが、心配なことに、リポジトリ全体でヒットが見つかりませんでした。
私はあなたの最善の策は住所を自由形式の複数行テキストとして扱うことだと思います。すべてのアドレスを検証できない可能性がありますが、一部のアドレス形式は実際には奇妙で予期せぬものであり、最終的に正しいアドレスを入力する責任はユーザーにあり、ほとんどのアプリケーションではユーザーが無効なアドレス。
バリデーターを使用してwarningを提供することもできますが、それ以上のものはありません。ただし、検証しないアドレスを拒否しないでください。そうしないと、顧客を失う可能性があります。これは、ユーザーが奇妙なアドレス形式の地域に住んでいる場合、警告を無視しても安全であることを伝える方法でユーザーに警告を伝える方法の問題につながります...