RDBMS に郵便住所を保存するためのベスト プラクティスに関する優れた参考資料はありますか? トレードオフが多数あり、それぞれに評価すべき長所と短所が多数あるようですが、これは何度も行われてきたはずです。誰かが少なくともどこかで学んだ教訓を書いたことがあるのではないでしょうか?
私が言及しているトレードオフの例としては、郵便番号を整数フィールドと文字フィールドのどちらで保存するか、番地を別のフィールドとして保存するか、住所 1 行目の一部として保存するか、スイート/アパートなどの番号を正規化するか、住所 2 行目にテキストのチャンクとして保存するか、郵便番号 +4 をどのように処理するか (別のフィールドか 1 つの大きなフィールドか、整数かテキストか) などがあります。
現時点では主に米国の住所について考えていますが、グローバル展開の将来に備えるためのベストプラクティスがいくつかあると思います (たとえば、州ではなく地域、郵便番号ではなく郵便番号など、フィールドに適切な名前を付けるなど)。
ベストアンサー1
より国際的な使用のために考慮すべき1つのスキーマは、Drupal アドレスフィールド. それは、xNAL 標準、ほとんどの国際的なケースをカバーしているようです。そのモジュールを少し調べると、国際的な住所の解釈と検証に役立つ情報がいくつか見つかります。また、ISO コード付きの行政区域 (州、州、州など) の優れたセットもあります。
モジュール ページからコピーしたスキーマの要点は次のとおりです。
country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)
私が学んだ教訓:
- 数値的には何も保存しないでください。
- 可能な場合は、国と行政区域を ISO コードとして保存します。
- わからない場合は、フィールドの要求については緩めてください。国によっては、
locality&などの基本的なフィールドでさえ、当然のことと思われるフィールドが使用されない場合がありますthoroughfare。