RDBMS に住所を格納するためのベスト プラクティスについて、適切な参考文献はありますか? 行うことができる多くのトレードオフがあり、それぞれに評価される長所と短所がたくさんあるようです-確かにこれは何度も何度も行われていますか? たぶん、誰かが少なくともどこかで学んだいくつかの教訓を書いたことがありますか?
私が話しているトレードオフの例は、郵便番号を整数と char フィールドとして保存することです。家番号は別のフィールドまたは住所行 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)
私が学んだ教訓：
locality一部の国では、 &のような基本的なものであっても、当然のことと思われるフィールドを使用しない場合がありますthoroughfare。「国際的な」ユーザーとして、米国形式のアドレスのみを対象とする Web サイトを扱うことほどイライラすることはありません。最初は少し失礼ですが、検証も熱心すぎると深刻な問題になります。
グローバル化に関心がある場合、私からの唯一のアドバイスは、自由な形式を維持することです。国によって規則が異なります。番地が通りの名前の前に来る国もあれば、後に来る国もあります。いくつかの州、いくつかの地域、いくつかの郡、およびそれらのいくつかの組み合わせがあります。ここ英国では、郵便番号は郵便番号ではなく、文字と数字の両方を含む郵便番号です。
郵便番号用の別のフィールドと一緒に、可変長文字列を最大 10 行にすることをお勧めします (そして、国民の感覚に対処するために、それをどのように記述するかに注意してください)。住所の書き方はユーザー/顧客に決定してもらいます。
他の国で住所がどのように使用されているかについての包括的な情報が必要な場合は、次の非常に優れたリファレンス リンク (コロンビア大学) を参照してください。
Frank's Compulsive Guide to Postal Addresses
効果的な国際郵便の宛名書き
「半角数字」や「129A」のような私の現在の住所などの特殊なケースのため、数字ではなく文字フィールドとして家番号を格納することを確実に検討する必要がありますが、A はアパートとは見なされません。配送サービスの番号。
私はこれを行いました (データベース内のアドレス構造を厳密にモデル化します) が、二度と行うことはありません。ルールとして考慮に入れなければならない例外がどれほど狂っているのか、想像もできません。
ノルウェーの郵便番号の問題をぼんやりと思い出します (私が思うに)、オスロは 18 かそこらありましたが、それ以外はすべて 4 桁でした。
私たちがすべての国内住所に地理的に正しい郵便番号を使用し始めた瞬間から、かなりの数の人々がメールの到着が遅すぎると不平を言い始めたことは確かです. それらの人々は郵便エリア間の境界線の近くに住んでいたことが判明し、誰かが実際に郵便エリア、たとえば1600に住んでいたという事実にもかかわらず、実際には彼のメールは郵便エリア1610に宛てられるべきです。それは実際に彼に仕えたので、彼の郵便物を正しい郵便局に送ると、その郵便物が届くまでに数日長くかかります.
（最終的に、ISOコード「ZZ」の国に海外の住所を持つ人々を登録することになりました。）
「これはリレーショナル データベースでアドレス情報をモデル化するための良い方法ですか」と必ず相談する必要がありますが、あなたの質問はその直接の複製ではありません。
確かに既存の回答がたくさんあります (たとえば、DatabaseAnswersのサンプル データ モデルを確認してください)。既存の回答の多くは、状況によっては欠陥があります (DB Answers をまったく選択していません)。
考慮すべき重要な問題の 1 つは、アドレスの範囲です。データベースが国際的な住所を扱う必要がある場合は、1 つの国の住所のみを扱う必要がある場合よりも柔軟にする必要があります。
私の見解では、多くの場合(常にというわけではありません)、住所の「住所ラベル イメージ」を記録し、内容を個別に分析することが賢明です。これにより、異なる国間など、郵便番号の配置の違いに対処できます。確かに、さまざまな国の奇抜さを処理するアナライザーとフォーマッターを作成できます (たとえば、米国の住所には 2 ～ 3 行あります。対照的に、英国の住所にはさらに多くの行があります。私が定期的に書き込む 1 つの住所には 9 行あります)。しかし、人間に分析とフォーマットを任せて、DBMS にデータを保存させる方が簡単な場合があります。
番地や郵便番号を計算する予定がない限り、それらを数値として保存することで将来の苦痛を招くだけです。
あちこちで数バイトを節約し、より高速なインデックスを取得できるかもしれませんが、米国の郵便またはあなたが扱っている他の国がコードにアルファを導入することを決定したとき、あなたはどうしますか?
ディスク容量のコストは、後で修正するコストよりもはるかに安くなります... y2k 誰かいますか?
@ジョナサン・レフラーと@ポール・フィッシャーが言ったことに追加
要件にカナダまたはメキシコの住所を追加することが予想される場合postal-codeは、文字列として保存する必要があります。カナダには英数字の郵便番号があり、頭のてっぺんからメキシコがどのように見えるかは覚えていません。
最小単位から最大単位まですべての可能なフィールドをリストするのが最も簡単な方法であることがわかりました。ユーザーは、適切と思われるフィールドに入力します。私のアドレステーブルは次のようになります。
*********************************
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 は役に立ちません。
これはやり過ぎかもしれませんが、複数の国で機能するソリューションが必要で、住所の一部をプログラムで処理する必要がある場合は、次のようにします。
10 個の VARCHAR2 列、10 個の数値列を含む汎用テーブル、およびこれらのフィールドをプロンプトにマップし、住所構造を国に結び付ける国列を持つ別のテーブルの 2 つのテーブルを使用して、国固有の住所を処理できます。
住所を確認したり、それを使用してクレジット カードの支払いを処理したりする必要がある場合は、少なくとも少し構造が必要になります。自由形式のテキスト ブロックは、そのためにはうまく機能しません。
郵便番号は、住所全体を使用せずに支払いカード取引を検証するための一般的なオプション フィールドです。したがって、そのために十分なサイズのフィールドを別に用意してください (少なくとも 10 文字)。
データベースの回答に触発されました
Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails
すべてのフィールドを大きなNVARCHAR（1000）フィールドにまとめ、ユーザーが値を入力するためのtextarea要素を使用します（たとえば、郵便番号で分析を実行する場合を除く）。これらすべての住所行1、住所行2などの入力は、その形式に適合しない住所がある場合は非常に煩わしいものです（そして、ご存知のとおり、米国以外の国もあります）。