このかなり一般的な内訳で、アドレスをDBテーブルに格納しているとします。
address_street_line_1,
address_street_line_2,
address_city,
address_state,
address_zip,
address_country_id
（注：さらに分割すること、通りのタイプ、家番号などに関する質問を読みました。このアプリケーションでは、不必要に複雑になると思います。）
海外のユーザーとうまく連携するには、これらのフィールドのどれが必須ではありませんか？
私はこれを考えています：
address_street_line_1 REQUIRED
address_city REQUIRED
address_country_id REQUIRED
州または郵便番号が必要ですか？
ありがとう！ザビエル
おそらく 1 つのフィールドのみを要求できます: 国。
しかし、実際にすべきことは、ロジックを国に依存させることです。包括的なリストについては、国別の住所形式をご覧ください。それは必須フィールドだけではありません。また、正しいフォーマットについてもです。米国の住所は次のようになります。
8031 メインストリート
スプリングフィールド OH 12345
USA
一方、スイスでは：
ボーデン通り 173
8043 チューリッヒ
シュヴァイツ
注:スイスでは番地と郵便番号が「逆」の順序になっています (英語圏の国と比較して)。
また、データ型は、他の国で使用されるデータをカバーするのに十分な広さである必要があります。郵便番号は絶対に数値型にしないでください。たとえば、「EC2R 8AH」は有効な英国の郵便番号です。
これは、この原則に戻ります。演算を実行しない場合、数値型ではありません。テキストです。
また、エンド ユーザーに郵便番号と呼ばないようにしてください。これは米国だけの用語です。それ以外のほとんどすべての場所で、郵便番号、郵便番号、または郵便番号を呼び出します。また、英国の郵便番号は英数字で、スペースが含まれていることに注意してください。
すべての国が郵便番号を使用しているわけではありません。たとえば、2006 年以前のニュージーランドではめったに使用されていませんでした。アイルランドはそれらをまったく使用していないと思います。
真に国際的な場合、シンガポールなどの都市国家は実際には City フィールドを必要としません。
ユーザー インターフェースでは、郵便番号が必要であることが既にわかっている国では、郵便番号を必須にすることができます (おそらくそうすべきです)。また、UI を十分に動的にすると、選択した国が米国の場合は「郵便番号」、カナダの場合は「郵便番号」、英国の場合は「郵便番号」などと呼ぶことができます。
street_line_2 と state を除くすべてを言います。「zip」は郵便番号ではなく、郵便番号のようなものだと考えてください。原産国に基づくさまざまな形式からわかるように、これはかなりオープンな形式にする必要があります。
不要にするのはどうですか？ユーザーが連絡を取りたい場合は、十分な情報を入力します。または、単一のテキスト フィールドを入力して、自由形式の情報を入力できるようにします。彼らはあなたよりも、郵便配達が彼らのドアに届くためにどのフィールドが必要かをよく知っています.
アメリカでもほとんどの住所は不要です。米国の郵便番号の大部分は、さまざまな企業や組織に割り当てられています。これらの郵便番号のいずれかへの郵便は、残りの住所に関係なく同じように配達されます。例えば：
ゼネラル エレクトリック
スケネクタディ、NY 12345
内国歳入庁
オグデン、ユタ州 84201-0027
市と州はいいですが、メールはおそらくなしで配達されます.
この問題を解決するために私が見つけた最善の方法は、永続層ではなく、アプリケーション層でロジックを抽象化することです。私が見た中で最もクリーンでシンプルな方法の 1 つは、ユーザーのデータを値オブジェクト (検証しやすい共通のインターフェイスを作成する) で渡すことで、現在の国コードを使用してバリデーターに渡します。これにより、すべての必要な属性が確認されます。そのロケールの値オブジェクトに適切に設定されています。検証に合格すると仮定して、値オブジェクトをアプリケーションの永続化側に渡して保存します。
ここで重要なのは値オブジェクトです。アプリケーションの複数の部分が対話、検証、読み取り/書き込みできる共通のインターフェイスを作成しています。次に、住所を表示するときに同じ値オブジェクトを使用することもできます。永続化レイヤーに情報を取得させ、それを値オブジェクトに入れ、それを現在のロケールを持つファクトリに渡し、目的の住所形式を返し、その出力をに送信します。フロントエンド。
実際、米国では都市は必要ありません。
多くの人々は州や郡の道路に地方の住所を持っています。郵便局のウェブサイトの出版物28に詳細があります。さまざまな企業が「都市」フィールドを使用して他の情報を保存することになります。これは、軍事基地の住所にも当てはまります。
郵便番号や市区町村で検索するなど、特定の検索を行わない場合は、すべての住所を 1 つのフィールドにまとめてください。このようにして、さまざまな国からのさまざまな住所をサポートします。
また、アドレスの奇妙な点もサポートします。
要件が変更されることが懸念される場合は、アドレスを Xml フィールドとして保存できます。Sql Server 2005 や 2008 などの最新のデータベースは、スキーマを使用している限り、Xml 列内の Xml ノードにインデックスを持つことができます。
それはすべて要件に帰着します。クライアントがグリッド内のデータを国別にグループ化する必要がある場合は、国列が必要です。
ニュージーランドには州がないため、間違いなくオプションである必要があります。したがって、あなたの質問には正しい答えがあると思います。
フィールドを必須にすることは常にトレードオフです。人が情報を入力したくない場合は、入力しません。「必須フィールド」の乳母を通過するために、ピリオドまたはゴミを入力します。
アプリでは street_address_1 のみが必要です。また、米国および多くの国では、郵便番号と正規の都市/州の間のマッピングを購入できます。高価ではありません。(個々の住所と郵便番号間のマッピングは、はるかにコストがかかります。) 米国については、http://www.usps.com/ncsc/addressinfo/citystate.htmを参照してください。
Ajax Web インターフェースを組み込む場合は、最初に国を尋ね、次に郵便番号を尋ねます。米国の場合は、Ajax を使用してユーザーの都市/州を zip から取得して入力します。
米国以外の一部の国、たとえば英国では、人々に「希望する住所」を記入するように求めている場合、3 行の住所を使用できます。例:
Mirassou (You can register a building's name with the post office
High Street as an alternative to its street number)
Old Town
City, Bucks postal_code
ラリー