海外のユーザーにデータベースを使用してもらいますが、米国以外でメールシステムがどのように動作するのかわかりません。

「都市」、「州」、「国」、そして「郵便番号」の概念は、階層が2レベルしかない場合でも階層をキャプチャするのに十分ですか（都市/国）。

1つのプレーンテキストフィールドを使用してください！

配信の最適化やその他の非常にローカルな使用のためにデータベースを構築している場合を除き、先に進んで標準の改行を含むテキストフィールドとして完全な住所を格納する必要があります。

必要な追加情報（郵便番号やソートやグループ化のための番地など）があり、一括メール割引が適用される場合は、追加のフィールドに保存するか、一部の方法でメール時に決定することができます。かなりシンプルなロジック。（または、各アドレスに永続的なキーを与え、割引情報を他のテーブルを介して提供することもできます。）

ここで、市区町村と州のリストを含む複数の部分からなる住所フォームと、おそらく国の郵便サービスの住所APIへの自動参照を提供するべきではないことを言っているわけではありませんが、フォームの作成方法については尋ねていませんユーザー入力、あなたはデータベースにアドレスを保存する方法を尋ねました。

もちろん、そのフォームを実行する場合、JSONまたはXMLブロブを格納してフィールドを再入力できるようにすることもできますが、それはデータベース自体が必ずしも考慮する必要があるデータではありません...

すべてのものと同様に、国際標準があります。この場合は、ISO / IEC 19773 Part 08：UPU郵便データのデータ構造です。しかし、国際標準でいつものように、それらは本当に複雑です。これは30ページあり、約50の可能な要素を定義します。これらの要素は、世界中のどこかで使用される可能性のあるすべてのアドレス指定スキームをカバーする完全な住所の一部にすることができます。

これはアドレスを格納する正しい方法かもしれませんが、実用的ではないかもしれません。

さまざまな国の住所がどのように見えるかの概要については、投稿アドレスに関するウィキペディアの記事をご覧ください。ご覧のとおり、ほとんどすべての国で人物、家の番号、通り、都市が使用されています（ただし、イランのように建物に数字ではなく名前が付いている場合や、一部の都市では座標系が使用されている場合など）。さらに、いくつかの国は地域に分割されており、いくつかの国はさらにそれらをサブ地域に分割しています。ほとんどの国では、長さが異なる郵便番号を使用しており、通常、地域、小地域、都市と同じ情報が含まれていると予想できますが、この情報は通常、郵便番号が正しいことを確認するために必要です。

それでは、真に国際的な住所データベースの開発者にとってそれはどういう意味ですか？柔軟です。フィールドを必須にせず、地域の癖を表すために使用できるいくつかのオプションの汎用フィールドを許可します。