65

国際的な地理的アドレスをリレーショナルテーブルに格納するタスクを考えると、最も柔軟なスキーマは何ですか？アドレスのすべての部分を独自のフィールドに分割する必要がありますか、それともフリーテキストのようにする必要がありますか？

異なる形式のアドレスを異なるテーブルに分割することに意味はありますか？たとえば、USAAddress、CanadianAddress、UKAddress ...のテーブルがありますか？

4

9 に答える 9

106

私のブログ投稿からの私の考えを要約します-アドレスストレージ（archive.org）のレッスン。

私の現在のプロジェクト[私は物流会社で働いています]では、国際的な住所を保存しています。私は、データベースのこの部分の設計において、世界中のアドレスについて調査を行いました。さまざまな形式があります。西洋の世界では、かなり統一された形式を使用する傾向があります-いくつかの違いがありますが、ほとんどは次のとおりです。

  • 番地-数値
  • 家または建物の名前-[VarChar-英国では、一部の家/建物は番号ではなく名前で識別されます]
  • 番地のサフィックス[VarChar、ほとんどの場合、Char（1）で十分です]
    • A、Bなど
  • ストリート名[VarChar]
  • ストリートタイプ[StreetTypesテーブルがある場合はVarCharまたはInt]
    • これまでのところ、私は英語圏の世界で262のユニークなタイプを見つけましたが、おそらくもっと多く、Strasse、Rueなどの他の言語を忘れないでください。
  • 通りの方向[VarChar（2）]
    • N、E、S、W、NE、SE、NW、SW
  • アドレスタイプ[AddressTypesテーブルがある場合はVarCharまたはInt]
    • 私書箱
    • アパート
    • 建物
    • 床
    • オフィス
    • スイート
    • 等...
  • アドレスタイプ識別子[VarChar]
    • つまり、ボックス番号、アパート番号、フロア番号はアパート番号を覚えており、オフィスには1Aのような英数字の情報がある場合があります
  • 地方自治体[自治体テーブルがある場合はVarCharまたはInt]
    • たとえば、村/村が町の前の住所に表示されている場合です。
  • City /Town [Citiesテーブルがある場合はVarCharまたはInt]
  • 統治地区[地区テーブルがある場合はVarCharまたはInt]
    • 州（米国）
    • 州（カナダ）
    • 連邦区（メキシコ）
    • 郡（英国）
    • 等...
  • 郵便エリア[VarChar]
    • ジップ（米国）
    • 郵便番号（カナダ、メキシコ）
    • 郵便番号（英国）
  • 国[国テーブルがある場合はVarCharまたはInt]

これはほとんどの国をカバーしているように見えますが、フィールドの順序は異なって表示される場合があります。表示形式のリストは、http： //www.bitboost.com/ref/international-address-formats.html#Formatsにあります。

たとえば、多くの国では、郵便番号は都市名の前にあり、通り番号は通りの名前の後にあります。カナダ、米国、英国では、通りの番号が通りの名前の前にあり、郵便番号（または郵便番号）が都市の名前の後にあります。

住所をさまざまな国に分けることについてのあなたの質問に答えて、私はそれを提案しません、それは他の分野での生活を難しくするでしょう-例えば報告。私が提供したフォーマットは、米国、カナダ、メキシコ、英国を問題なくカバーするロジスティクスデータベースのすべてのアドレスをカバーしています。また、ヨーロッパ、中国、日本、マレーシアのすべての住所をカバーしています。他の国について話すことはできませんが、これらのフィールドでサポートされていない国の住所を保存する必要はまだありません。

英数字の文字列からアドレス情報を解析することは、最初に思われるほど単純ではないため、他の人が提案し、多くのデータベースで見られるAddress1、Address2、Address3形式を使用することはお勧めしません。特に、データが正しく入力されていない場合はそうです。 、誤った情報、タイプミス、スペルミスなどが原因です。フィールドを区切る場合は、距離アルゴリズムを使用して考えられる意味を確認したり、確率を使用して番地を郵便番号や番地と照合したり、州や市を番地などと照合したりできます。番地全体を示す文字列がある場合は、そのいずれかを実行します。それは想像力の範囲によって些細なことではありません。

住所データベースのQAは、頭痛の種です。この分野での生活を簡素化する最も簡単な方法は、すべてのフィールドに、入力時に正しいと自動的に確認できる単一の情報のみが含まれていることを確認することです。確率、距離アルゴリズム、および正規表現は、入力の有効性をチェックし、ユーザーの間違いが何であるかについてフィードバックを提供し、適切な修正を提案することができます。

注意すべき注意点の1つは、通りのタイプでもある名前の道路です。カナダをカバーしている場合は、トロントの「アベニューロード」に注意する必要があります。これは、Address1、2を使用している場合に非常に時間がかかります。 、3フォーマット。これは他の場所でも発生する可能性がありますが、私はそれらに気づいていません-この単一のインスタンスは私がWTFを叫ぶのに十分でしたか？！

于 2009-07-21T15:42:31.350 に答える
26

アドレス形式を過度に分析しないように注意してください。そうすると、ほとんどのユーザーが回避する必要のある仕様になってしまう可能性が高く、効果的に間違ったフィールドを使用するように強制するか、プライマリフィールドのみに入力して余分なフィールドを無視します。

物事をシンプルにしてください。

BenAlabasterが言及しているようなStreetTypeは、英語やスペイン語などの孤立語とは異なる言語で作業を開始するときに問題を引き起こします。

アムステルダムの「HenrietteRolandHolststraat」は、「Henriette」+「RolandHolst」+「straat」から構成され、「Roland Holststraat」、または「 Roland Holststr。」、または「HRHolststr。」のスペルミス。または「ヘンリエッテローランド-ホルスト通り」、天候に応じて。地球上の各国の最新のストリートレジスターを持っていない限り、どこにも行きません。

そして最後に、多言語の国によっては、名前が言語ごとに異なる場合があることに注意してください。たとえば、ブリュッセルでは、多くの通りにフランス語とオランダ語の両方の名前が付けられています。宛先の優先言語に応じて、「AvenuduPort」と「Havenlaan」があります。（Googleマップでは、念のため、両方の名前を交互に表示しています。）

ここではあらゆる種類の巧妙なトリックを考案することができますが、それは営業担当者です。これを理解するつもりですか？

于 2009-07-23T16:51:18.430 に答える
8

それはあなたがそれで何をしたいかによります。

アドレスが分離されていると、他の目的（USPSデータに対する検証やUPS / FEDEXからの配送料の取得など）でアドレスを使用する方が常に簡単であることがわかりました。

私が通常アドレスに使用するものは次のとおりです。

  • 住所1
  • 住所2
  • 住所3行目
  • 街
  • 領域
  • 郵便番号
  • 郡
  • 国

編集への応答： ほとんどの状況で、私は使用法を見ていません。上にリストした表には、ほとんどの国の住所に対して十分なフィールドがあります（そして十分に一般的です）。

于 2009-07-21T15:06:05.447 に答える
8

この質問に出くわした人のための逸話は次のとおりです。

私は多くの大陸（ヨーロッパ、アジア、北アメリカ）に住み、働いてきた人として話します。私の経験、および私が一緒に働く人々の経験では、次のことを行うシステムを使用する方がはるかに簡単でした。

  1. 1つのアドレスを入力する3行を入力します。私がそれらを逐語的にタイプするとき、これらの3行をあなたの地元の郵便局に渡してください。好きな文字セットを使用させてください。UTF-8またはそれ以上のものを使用してください。
  2. システムに特定の情報（郵便番号、県、州など）を指定する必要があるビジネス要件がある場合は、別途それを要求してください。ビジネス要件とは、分析などを意味します。これらの情報は、地元の郵便局と共有しないでください（上記のポイント1の3行のいずれかに同じ情報を書き込んだ場合を除きます）。
  3. 上記のポイント1の行で指定した住所のカテゴリ別の場所（おそらく国）を指定するように求めるドロップダウンがあります。
  4. ポイント1の行で提供する情報を解析する必要がある場合は、ポイント3に対する私の回答を使用して正規表現を選択してください。ポイント1の情報に対してその正規表現を実行して、解析します。正規表現からの出力を使用して、ポイント2のユーザーインターフェイス要素を埋めてみてください。自動入力された情報を修正する場合は、正規表現を改善するために変更したという事実を使用してください。同様に、可能な限り、正規表現の出力を確認して修正する機会を与えてください。私が伝えようとしていることを私ほどよく知っている人は誰もいません。

このように構築されたシステムは、私の人生を最も楽にしてくれます。特に、あなたの会社が実質的に機能的な内部知識を持っていない郵便システムにメールを送るとき。

あなたの会社が特定の郵便システムに関する内部知識を持っている場合は、ポイント3での私の選択を使用して、どのビューを表示するかを通知してください。多くの人々は、米国の郵便システムがパッケージングに何を期待しているのかを知っています。ポイント3で米国を選択した場合は、ビューが米国の住所に適しているように見せてください。あなたの会社が何も知らない国を選択した場合、一般的な3行を表示し、残りは私に任せてください。ASCIIの使用を強制しないでください。

そして、ここで現実になりましょう。すべてのグローバルな郵便システム（公的および私的）の完全な百科事典データベースを構築することは、不可能ではないにしても、せいぜい非常に困難な作業です。たとえば、住所がどこにあるかを実際に知っているのは、地元のラストマイルの運送業者だけである郵便システムがあります。パッケージ上のそのキャリアにメモを渡すことができると、非常に便利な場合があります。そして、すべてのエッジケースキャリアのローカル知識をデータベースにマッピングすることは、確かに不可能な作業です。

ゲーデルに聞いてください。（そして、あなたが談話の宇宙をモデル化するために公理的システムを使用しようとしているのか、集合論や関係代数のようなある種の算術を与えるか取るのかを自問してください。）

于 2017-06-01T17:12:23.820 に答える
7

住所

@BenAlabasterが提供した優れた答えとは正反対なので、次のようにすることができます。

address       TEXT(300)
postal_code   VARCHAR(15)
country_code  VARCHAR(2)

クライアント側のフォームのレイアウトは、必要に応じて複雑にすることができます（または、ユーザーが手動でアドレスを入力できる複数行の入力を使用することもできます）。その後、必要に応じてアドレスに改行を追加できます。

国

国の表は次のようになります。

country_code  VARCHAR(2)
country_name  VARCHAR(255)

さらに、次のいずれかを使用できます。

postal_code_required  TINYINT(1)
postal_code_regex     VARCHAR(255) NULL DEFAULT NULL

次に、次のリストを使用して国別テーブルを設計します。

于 2014-02-21T16:25:56.977 に答える
2

Ben Alabasterの回答のコメント：国に基づいて住所をフォーマットするには、各国の列の順序を個別の行として持つフォーマットテーブルを使用できます。

  • AddressFormat（CountryCode、FieldName、FieldOrder）

フィールドの順序は、複雑なグリッドレイアウトを使用するようにコーディングすることもできます。

国ごとに住所を分ける意味はありません。これは国の数が増えるにつれて混沌とし、たとえば国際的なクライアントのすべての住所を見つけたい場合は問題が発生します。ベンによって提案された住所タイプがあると、建物番号とアパート番号の両方を持つ住所がある場合にもあいまいさが生じる可能性があります。私は、建物ごとに名前が異なる集合住宅にいる可能性があります。これはインドでは非常に一般的です。

于 2009-07-23T08:42:26.600 に答える
2

https://github.com/commerceguys/addressingライブラリを使用して国際住所をフォーマットし、次の要素を使用します。

Country
Administrative area
Locality (City)
Dependent Locality (in: BR, CN, IR, MY, MX, NZ, PH, KR, ZA, TH)
Postal code
Sorting code
Address line 1
Address line 2
Organization
Recipient

これは、通り（名前、家番号など）を解析する場合には役立ちません。

ところで。多言語の国リストをお探しの場合：https ：//github.com/umpirsky/country-list

于 2016-08-22T15:53:03.880 に答える
0

唯一の方法は、それらを次のように分割することです。

Name varchar,
Title varchar,
StreetAddress varchar,
StreetAddressLine2 varchar,
zipCode varchar,
City varchar,
Province varchar,
Country lookup

ほぼすべての国に住所データを保持するための独自の標準があり、国ごとに異なる形式の郵便番号があるためです。同様の質問から、私の投稿
に問題の小さなサンプルを含めることができます。

住所の規則がほとんどない国もあるため、これは国ごとに住所を分けることには意味がありません。いくつかの人気のある慣習には、小さな村には通りがなく、村の名前と番号だけがあり、通りは大都市の住所にあります。ハンガリーの首都ブダペストでは、同じ名前の街路はほとんどありませんが（都市の地区番号で区別します）、他の都市にはそのような住所がありません（ハンガリーの誰かが実際にこれが正しいかどうかを確認する場合があります）。したがって、住所形式の総数は、numer_of_countriesにこの国の住所形式の数を掛けたものになります…さまざまなテーブルで実行できますが、実行するのは恐ろしい作業になります。

于 2009-07-21T15:05:12.747 に答える
0

これはすでに答えられている非常に古いトピックであることを私は知っていますが、私も2セントを投入すると思いました。それはすべて、プロジェクトの目標と、ターゲットユーザーがアドレスを入力する方法によって異なります。ベンの提案により、アドレスを正確に解析できるようになりますが、一方で、ユーザーデータ入力プロセスが長くなる（場合によってはイライラする）可能性があります。Stephen Wrightonの提案はより単純であり、結果としてユーザーがアドレスを入力するのがより簡単になる可能性があります。

また、都市、国、地域などを維持しながら、一般的な番地、タイプ、番地、ユニット/アパート番号などをすべて1つの列にキャプチャする「住所」列を単純に持つモデルもいくつか見ました。他の列内。スティーブンのモデルと似ていますが、Address1、Address2、およびAddress3がすべて1つの列に統合されている点が異なります。

私の意見では、最も柔軟なモデルは、柔軟性の解釈に応じて、最も制限の少ないモデルになる傾向があります。

于 2010-09-08T13:31:09.907 に答える