データベースに住所を保存するためのベストプラクティス（RDBMS）
RDBMSに住所を保存するためのベストプラクティスの参考資料はありますか？評価できるトレードオフがたくさんあり、それぞれに長所と短所がたくさんあるようです-確かにこれは何度も行われていますか？誰かが少なくともどこかで学んだいくつかの教訓を書かれているのでしょうか？
私が話しているトレードオフの例は、郵便番号を整数と文字フィールドとして格納することです。ハウス番号は別のフィールドまたは住所行1の一部として格納する必要があります。アドレス行2のテキストのチャンク、Zip +4（個別のフィールドまたは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などの基本的なものでさえ、当然のことと思われるフィールドを使用しない場合があります。
「国際」ユーザーとして、米国形式の住所のみを対象とするWebサイトを扱うことほどイライラすることはありません。最初は少し失礼ですが、検証も熱心すぎると深刻な問題になります。
グローバル化に関心がある場合、私が持っている唯一のアドバイスは、物事を自由形式にすることです。国によって異なる慣習があります-ある場合には、番地の前に番地があり、ある場合には後です。州、地域、郡、それらの組み合わせを持つ国もあります。ここ英国では、郵便番号は郵便番号ではなく、文字と数字の両方を含む郵便番号です。
可変長文字列と郵便番号用の別のフィールドを合わせて、単純に10行以内にすることをお勧めします（また、国の感性に対処するためにそれをどのように記述するかに注意してください）。ユーザー/顧客にアドレスの書き込み方法を決定させます。
「半数」などの特殊なケースや、「129A」などの現在の住所のために、家番号を数字ではなく文字フィールドとして保存することを必ず検討する必要がありますが、Aはアパートとは見なされません配送サービスの番号。
他の国での住所の使用方法に関する包括的な情報が必要な場合は、非常に優れたリファレンスリンク（コロンビア大学）をご覧ください。
フランクの郵便住所への強制ガイド
国際メールの有効なアドレス指定
私はこれを行いました（データベース内のアドレス構造を厳密にモデル化します）し、二度とそれをすることはありません。例外がどれほど狂っているかを想像することはできませんが、原則として考慮する必要があります。
ノルウェーの郵便番号（私は思う）の問題を漠然と思い出します。これは、18か所あるオスロを除いて、すべて4つの役職でした。
私たちの住所のすべてに地理的に正しい郵便番号を使用し始めた瞬間から、かなりの数の人々がメールの到着が遅すぎると不平を言い始めたと確信しています。それらの人々は郵便区域の境界線近くに住んでいたことが判明し、実際に誰かが郵便区域に住んでいたという事実にもかかわらず、例えば1600年、実際には彼の郵便は郵便区域1610に宛てられるべきである。それは実際に彼に役立ったので、彼のメールを正しい郵便エリアに送信すると、その郵便が到着するまでに数日かかるでしょう、なぜなら正しい郵便局でそれを間違った郵便エリアに転送するために必要な不必要な介入のためです...
（私たちは、ISOコード「ZZ」でその国の海外に住所を持つ人々を登録することになりました。）
確かに「 これはリレーショナルデータベースの住所情報をモデル化するのに適した方法ですか 」を参照する必要がありますが、あなたの質問はその直接の複製ではありません。
確かに多くの既存の答えがあります（たとえば、 DatabaseAnswers のサンプルデータモデルを確認してください）。既存の回答の多くは、状況によっては不完全です（DB Answersをまったく選択しません）。
考慮すべき主要な問題の1つは、アドレスの範囲です。データベースで国際住所を処理する必要がある場合は、1つの国の住所のみを処理する必要がある場合よりも柔軟にする必要があります。
私の見解では、often（つまり、alwaysではありません）住所の「住所ラベル画像」を記録し、コンテンツを個別に分析するのが賢明です。これにより、異なる国間など、郵便番号の配置の違いに対処できます。確かに、異なる国の離心率を処理するアナライザーとフォーマッターを作成できます（たとえば、米国の住所には2行または3行がありますが、英国の住所にはかなり多くあります;定期的に書き込む1つの住所には9行あります）。しかし、人間に分析とフォーマットを行わせ、DBMSにデータを保存させるだけの方が簡単です。
番地や郵便番号で数学をするつもりでない限り、あなたはそれらを数値として保存することによって将来の痛みを招いているだけです。
あちこちで数バイトを節約し、より速いインデックスを取得するかもしれませんが、米国の郵便、またはあなたが扱っている他の国がコードにアルファを導入することを決定したとき、あなたは何をしますか？
ディスクスペースのコストは、後で修正するよりもはるかに安くなります... y2k誰か？
私は、最小単位から最大単位まで可能なフィールドをすべてリストするのが最も簡単な方法であることに気付きました。ユーザーは、適切と思われるフィールドに入力します。私のアドレステーブルは次のようになります。
*********************************
Field Type
*********************************
address_id (PK) int
unit string
building string
street string
city string
region string
country string
address_code string
*********************************
@ Jonathan Leffler と@ Paul Fisher が言ったことに加えて
カナダまたはメキシコの住所が要件に追加されると予想される場合は、postal-codeは文字列として必須です。カナダには英数字の郵便番号があり、メキシコが私の頭上からどのように見えるか覚えていません。
ZipをNUMBERまたはVARCHARとして保存する場合の「トレードオフ」はどこですか？これは単なる選択です。両方にメリットがあり、他のメリットを得るためにいくつかのメリットを放棄する必要がない限り、トレードオフではありません。
Zipの合計にまったく意味がない限り、Zips as numberは役に立ちません。
これはやり過ぎかもしれませんが、複数の国で機能するソリューションが必要で、住所の一部をプログラムで処理する必要がある場合：
10個のVARCHAR2列、10個の数値列、これらのフィールドをプロンプトにマップし、住所構造を国に関連付ける国列を持つ別の表の2つの表を使用して、国固有の住所を処理できます。
住所を確認したり、住所を使用してクレジットカードの支払いを処理したりする必要がある場合は、少なくとも少しの構造が必要です。自由形式のテキストブロックは、そのためにはうまく機能しません。
郵便番号は、住所全体を使用せずに支払いカードの取引を検証するための一般的なオプションフィールドです。そのため、そのための独立した寛大なサイズのフィールド（少なくとも10文字）を用意します。
Database Answers に触発された
Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails
すべてのフィールドを大きなNVARCHAR（1000）フィールドにまとめ、ユーザーが値を入力するためのtextarea要素を使用します（郵便番号などの分析を実行する場合を除く）。これらの住所1行目、住所2行目などの入力はすべて、その形式に合わない住所がある場合は非常に面倒です（そして、米国以外の国もあります）。