データベース（RDBMS）に住所を保存するためのベストプラクティス

RDBMSに住所を保存するためのベストプラクティスに関する適切なリファレンスはありますか？評価できるトレードオフはたくさんあり、それぞれの長所と短所がたくさんあるようです-確かにこれは何度も何度も行われていますか？たぶん誰かが少なくともどこかで学んだいくつかのレッスンを書いたことがありますか？

私が話しているトレードオフの例は、郵便番号を整数フィールドと文字フィールドとして格納すること、家番号を別のフィールドまたは住所行1の一部として格納する場合、スイート/アパートメント/その他の番号を正規化するか、または単に住所行2のテキストのチャンク。zip+4（個別のフィールドまたは1つの大きなフィールド、整数とテキスト）をどのように処理しますか？等

この時点では主に米国の住所に関心がありますが、グローバルになる可能性に備えていくつかのベストプラクティスがあると思います（たとえば、州ではなく地域や郵便番号ではなく郵便番号などのフィールドに適切な名前を付ける）等

より国際的な使用のために、考慮すべき1つのスキーマはDrupal Address Fieldによって使用されるものです。これは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。

「国際的な」ユーザーとして、米国形式のアドレスのみを中心としたウェブサイトを扱うことほど苛立たしいことはありません。最初は少し失礼ですが、検証も熱心すぎると深刻な問題になります。

グローバル化に関心がある場合、私が唯一のアドバイスは、物事を自由形式に保つことです。国によって表記規則は異なります。番地の前に番地が付いている場合もあれば、後になっている場合もあります。いくつかは州、いくつかの地域、いくつかの郡、それらのいくつかの組み合わせを持っています。ここ英国では、郵便番号は郵便番号ではなく、文字と数字の両方を含む郵便番号です。

可変長の文字列を10行以下に、郵便番号用の個別のフィールドと共に（そして国の感性に対処するためにそれをどのように説明するかに注意して）ください。ユーザー/顧客に自分のアドレスを書き込む方法を決定させます。

他の国が住所をどのように使用しているかについての包括的な情報が必要な場合は、非常に優れた参照リンク（コロンビア大学）をご覧ください。

フランクの強迫的な郵送先案内書
国際郵便の効果的な宛先指定

"半数"や "129A"のような現在の住所などの特殊なケースのため、家の番号を数字ではなく文字フィールドとして格納することを検討してください。ただし、Aはアパートとは見なされません。配送サービスの番号。

私はこれを実行しました（データベースのアドレス構造を厳密にモデル化しています）。原則として考慮しなければならない例外がどれほどクレイジーかは想像できません。

ノルウェーの郵便番号に関するいくつかの問題を漠然と思い出します（私が思う）、18かそこらを持っているオスロを除いて、すべて4つのポジションでした。

私たちがすべての自国の住所に地理的に正しい郵便番号を使い始めた瞬間から、かなりの数の人々がメールの到着が遅すぎると不平を言い始めたと確信しています。それらの人々は郵便区域間の境界線近くに住んでいることが判明しました、そして誰かが郵便区域に実際に住んでいたという事実にもかかわらず、たとえば1600、実際には彼の郵便は郵便区域1610に宛てられるべきです。それは実際に彼に仕えたので、彼の郵便を彼の正しい郵便区域に送ることは、正しい郵便局が間違った郵便区域にそれを転送するために必要とされた不必要な介入のために、到着するまでに数日かかるでしょう...

（私たちは、ISOコード「ZZ」を使用して、国の海外住所を持つ人々を登録することになりました。）

「リレーショナルデータベースでアドレス情報をモデル化するのにこれは良い方法ですか」を必ず確認してください。

確かに多くの既存の回答があります（たとえば、DatabaseAnswersのサンプルデータモデルをチェックしてください）。既存の回答の多くは、状況によっては不完全です（DB Answersをまったく選択していません）。

考慮すべき1つの主要な問題は、アドレスの範囲です。データベースで国際住所を処理する必要がある場合は、1つの国の住所のみを処理する必要がある場合よりも柔軟にする必要があります。

私の見解では、住所の「住所ラベル画像」を記録し、内容を個別に分析することは、（常にというわけではありませんが）しばしば賢明です。これにより、たとえば国間の郵便番号の配置の違いに対処できます。もちろん、さまざまな国の偏心を処理するアナライザーとフォーマッターを作成できます（たとえば、米国の住所には2行または3行ありますが、対照的に、英国の住所にはかなり多くの行がある可能性があります。定期的に書き込む1つの住所には9行あります）。しかし、人間に分析とフォーマットを行わせ、DBMSにデータを格納させるだけの方が簡単です。

番地や郵便番号で計算を行うのでない限り、それらを数値として保存することで将来の苦痛を招くだけです。

あなたはあちこちに数バイトを節約し、おそらくより速いインデックスを取得するかもしれませんが、米国の郵便、またはあなたが扱っている他の国がコードにアルファを導入することを決定したとき、あなたは何をしますか？

ディスク容量のコストは、後で修正するコストよりもはるかに安くなります... y2k誰か？

@ ジョナサンレフラーと@ ポールフィッシャーが言ったことに追加

カナダまたはメキシコの住所を要件に追加する予定がある場合postal-codeは、文字列として保存する必要があります。カナダには英数字の郵便番号があり、頭上からメキシコがどのように見えるか覚えていません。

Iveは、最小の離散単位から最大までのすべての可能なフィールドをリストすることが最も簡単な方法であることを発見しました。ユーザーは自分が適切だと思うフィールドに入力します。私のアドレステーブルは次のようになります。

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

ZIPをNUMBERまたはVARCHARとして保存する際の「トレードオフ」はどこにありますか？これは単なる選択肢です。両方にメリットがあり、他のユーザーを獲得するためにいくつかのメリットを放棄する必要がある場合を除いて、トレードオフではありません。

zipの合計がまったく意味がない場合を除いて、数値としてのZipは役に立ちません。

これはやり過ぎかもしれませんが、複数の国で機能するソリューションが必要で、アドレスの一部をプログラムで処理する必要がある場合：

2つのテーブルを使用して国固有の住所処理を行うことができます。1つの汎用テーブルは10のVARCHAR2列、10の列、これらのフィールドをプロンプトにマップし、国の列を国に関連付ける国の列を持つ別のテーブルです。

住所を確認したり、クレジットカードの支払いを処理するために住所を使用したりする必要がある場合は、少なくとも小さな構造が必要になります。そのため、自由形式のテキストブロックはあまり機能しません。

郵便番号は、住所全体を使用せずに支払いカード取引を検証するための一般的なオプションのフィールドです。そのため、個別の十分なサイズのフィールド（少なくとも10文字）を用意してください。

データベースの回答に触発

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

ユーザーが値を入力するためのtextarea要素を使用して、すべてのフィールドを大きなNVARCHAR（1000）フィールドにまとめます（郵便番号などで分析を実行する場合を除く）。これらの住所行1、住所行2などのすべての入力は、その形式に適さない住所がある場合は非常に煩わしいです（そして、ご存知のとおり、米国以外の国もあります）。