SQLデータベースにアドレスを保存するためのベストプラクティス/標準
米国の住所をデータベースに保存するためのある種の「標準」があるかどうか疑問に思っていますか？これは一般的な作業のようであり、ある種の標準があるはずです。
私が探しているのは、データベーステーブルがどのように機能し、相互作用するかについての特定のスキーマであり、データ型（MySQL）を含む第3正規形になっています。優れたUMLドキュメントが機能します。
たぶん私は怠け者ですが、これは非常に一般的なタスクであり、誰かがこれをどこかで行うための効率的な方法を公開していると確信しています。どこを見ればいいのかわからず、Googleは助けてくれません。リソースを教えてください。ありがとう。
編集
これはより一般的な質問ですが、私の具体的なニーズを明確にしたいと思います。
アドレスは、イベントの場所の道路アドレスを指定するために使用されます。これらのアドレスは、最適に分類して検索できる形式である必要があります。また、データソースをリンクする可能性のあるサードパーティのアプリケーションでも使用できます。
また。データは入力時にジオコーディング（long、lat）され、個別に保存されるため、ジオコーダー/アプリケーション/ライブラリが行う（まだ決定されていない）プロトコルに適合している必要があります。
http://www.upu.int には、国際住所のフォーマット標準があります。 http://usps.com のPublication 28には、米国のフォーマット標準があります。
USPSは、次の句読点のない住所コンポーネントを1行に連結する必要があります。
* house number
* predirectional (N, SE, etc)
* street
* suffix (AVE, BLVD, etc)
* postdirectional (SW, E, etc)
* unit (APT, STE, etc)
* apartment/suite number
例：102 N MAIN ST SE APT B。
アドレス行全体をデータベースの単一フィールドとして保持する場合、入力と編集は簡単ですが、検索がより困難になる可能性があります（たとえば、SOUTH EASTLANEがSEAST LNのようにストリートEASTである場合、またはLANEの場合SE LANE STで？）。
住所を個別のフィールドに解析しておくと、通りの名前やアパートなどのコンポーネントの検索が簡単になりますが、出力するにはすべてを一緒に追加する必要があります。正しく解析するにはCASSソフトウェアが必要です。私書箱、地方のルートアドレス、APO/FPOアドレスには特別な解析があります。
その場所に複数の住所がある物理的な場所は、複数ユニットの建物であり、その場合、APTおよびSTEのようなユニットの後の文字/数字が住所を指定するか、または私設私書箱です。 UPSストア）およびメールドロップ/プライベートメールボックス番号が追加されているか（100 MAIN ST STE B PMB 102など）、またはUSPS配信ポイントが1つあるビジネスであり、メールはUSPS配信後にルーティングされます（通常、会社が別のメールストップフィールドを必要とします）。必要かもしれませんが、USPSは住所行に必要ありません）。
複数の住所を持つ連絡先は、通常、住所と私書箱を持つ会社または個人です。アドレスごとに異なる郵便番号を持つのが一般的であることに注意してください。
1つのビジネストランザクションに配送先住所と請求先住所が含まれるのは非常に一般的です（ここでも、郵便番号が異なります）。私が各アドレスについて保持している情報は次のとおりです。
* name prefix (DR, MS, etc)
* first name and initial
* last name
* name suffix (III, PHD, etc)
* mail stop
* company name
* address (one line only per Pub 28 for USA)
* city
* state/province
* Zip/postal code
* country
私は通常、人の名前と会社の間のどこかにメールストップを印刷します。これは、国には、人を含むメールストップを含む会社を含む住所を含む都市を含む州/郵便番号が含まれているためです。 CASSソフトウェアを使用して、入力または編集時に住所を検証および標準化します。
まず、専門家の1日のほとんどを住所の処理に費やしているため、データの観点から管理するのは困難です。
5人に、住んでいる住所を尋ねると、 5つの異なる答えが得られることがわかります。あなたと私はそれを言うことができますが123 Main Street Apt 1とApt 1 123 Main Streetが同じアドレスである場合、データベースプログラムに課題が発生します。
米国中心の住所を使用している場合、ほとんどすべてのベンダーのCASS認定ソフトウェアが、住所を適切に標準化します。次のような単純な形式をお勧めします。
- 住所（1
- アドレス2
- 住所3
- 市
- 状態
- ジップ
- Zip + 4（重複をチェックするときに検索が簡単になるように、これを携帯します）
ただし、ユニバーサルアドレスが必要な場合は、IdeaAllianceの [〜＃〜] adis [〜＃〜] 標準を確認します。この標準は、ほぼすべての国の住所を関連する部分に分解（解析）するために使用できます。次に、万国郵便連合の標準（国際郵便住所コンポーネントおよびテンプレートに関するUPU S42標準）に基づくテンプレート/コンポーネントを使用して、それらを元に戻すことができます。
この形式の大きな利点は、CASSのような郵便データベースに存在しないアドレスを個別の部分として入力および保存できることです。
まず、アドレスを保存する「最良の」手段は、その使用方法に大きく依存します。それは、参照またはたとえば都市での検索のためだけですか？封筒に対処する予定はありますか？ FedExやUPSなどの配送システムと統合しますか？米国以外の住所を保存しますか？出荷されるものと統合する領域に入ったら、 [〜＃〜] cass [〜＃〜] を検討し始める必要があります。これは、USPSアドレスを処理するための仕様です。住所を保存および検証するCASS認定のアプリケーションがあります。したがって、2番目のベストプラクティスは、車輪の再発明を避け、特に国際化する場合に問題を解決するシステムがあるかどうかを確認することです。自分で調査するのではなく、他の誰かが世界中の多くの国の住所を適切かつ効率的に保存する方法に関するすべての詳細を理解したという事実を活用したいと考えています。
私は以前にこれを試みなければならなかった、そして私はあなたにいくつかの指針を与える この文書 を見つけた。アプリケーションが国際アドレスを処理する必要があるため、スキーマを棚上げすることになりました。
私は少し前にこれを調べましたが、国際的な住所についてです。コンセンサスの邪魔になるものはあまり見つかりませんでした。ただし、米国の場合、簡潔に名前が付けられたUnited States Thoroughfare、Landmark、and Postal Address Data Standard（Draft）：
http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/index_html
それらが実際に特定のデータベーススキーマのアイデアを提供しているとは思いませんが、それは良い出発点かもしれません。