住所を個々の列に分割すると、どのような問題が解決しますか？

ソフトウェア開発者向けにテーブルとリレーションを設計するチームがあります。私たちの組織では、彼らは3NF正規化の実施について非常に厳しいです。正直に言うと、私たちの組織の規模と、ニーズやクライアントが時間とともにどのように変化するかを考えると同意します。設計決定の背後にある理由について明確になっていない領域は、アドレスのみです。

これは主に米国の住所に焦点を当てていますが、これはこれを行うすべての国に当てはまると思います。住所の各部分は、住所テーブルの独自の列を取得します。たとえば、この厄介な米国の住所を使用します。

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

次のようにデータベース内で分割されます。

• 番地：485
• ストリートフラクション：1/2
• ストリートプレディレクショナル：N（北）
• 通りの名前：スミス
• 通りのタイプ：ST（通り）
• ストリートポスト方向：SW（南西）
• 市：シカゴ
• 州：IL（イリノイ州）
• 郵便番号：11111
• Zip4コード：2222
• 国（米国を想定）
• 注意：ジェーンドゥ
• 私書箱：NULL
• 住居の種類：APT（アパート）
• 住居番号：300B

また、田舎のルートと契約ルートに関連する他の列がいくつかあります。さらに、特定のアプリケーションには、いくつかの国際アドレスが含まれている可能性があります。データモデラーは、国際住所に固有の列を追加すると述べました。これは通常の行1、行2のフィールドです。

最初は、これはWAYオーバーボードだと思いました。オンラインで繰り返し調べるとは、住所1、2、3、場合によっては4を使用してから、都市、地域、郵便番号を分割することです。この粒度が有益な新しいアプリケーションのユースケースが1つあります。ユーザーが重複したビジネスを作成していないことを検証する必要があり、住所の確認は検証の1つです。私たちはできるアドレスライン1と2で動作するようにそれを得るが、それはより困難になるであろう。

特定のアプリケーションに関しては、ビジネスと人々（物理、郵送、出荷など）のために複数の種類のアドレスを保存する必要があります。我々は可能性がある印刷可能な形式の文字を生成する必要がありますが、その要件は、これまで議論されていません。

組織内のアプリケーションがサポートする必要があるその他の事項：

• 監査（完全な履歴テーブルを使用）
• 宛名ラベルの印刷
• 印刷フォームの生成
• 報告（国および地方政府向け）

私たちのアプリケーションは、他のすべてのアプリケーションが行っていることをすべて行っているわけではありませんが、アドレスを複数のコンポーネントに分割することは、私が働いている企業標準です。アプリケーションがその恩恵を受けるかどうかに関係なく、私たちはこれを強制されます。

半関連のStackOverflowの質問：閉じられた良いアドレスパーサーはどこにありますが、アドレスの解析がどれほど難しいかを示しています。

私が彼らの設計決定をよりよく理解し、アイデアでクライアントを売るために...

住所を個々の列に分割すると、どのような問題が解決しますか？

問題が発生したため、このようなシステムを実装した人にとってのボーナスポイント。

分割によって解決できる問題には、次のものがあります。

検証名前の任意の部分をマスターリストと比較できます。一致しないものは拒否できます。郵便番号/郵便番号は明らかな例です。これらは、独立した機関によって発行および管理されます。有効なものは、その機関によって発行されたものだけです。

仕分けと選択メールがすでにある程度整理された配送サービスに渡されると、郵便料金が減る場合があります。対応する列があると、具体的なビジネス価値が生まれます。

分析注文がどこに向かっているのかを地理的に階層的に知ることは有用です。これにより、販売イニシアチブ、製品開発、コミッションの支払いなどが促進される可能性があります。

コードの複製組織内のすべてのアプリケーションに同じデータモデル（最も複雑な消費者のもの）を採用させることにより、単一のコードベースを企業全体に採用し、一貫して維持できます。無限に複製された髪の毛の分裂は避けられるか、少なくともプロペラヘッドに委ねられます。組織のさまざまな部分が保持するアドレスは、一貫して更新できます。カスタマーサービスと満足度を高めることができます。開発作業は、システムのユニークで価値の高い部分に集中できます。

法的問題法律と税金は管轄によって異なります。詳細なアドレス値を個別にキャプチャすることにより、トランザクションデータをコンプライアンス要件に相互参照することが容易になります。

複製 1つの要素を次の行に移動するか、一部の部分を並べ替えることにより、テキストとして保持されているアドレスをスプーフィングするのは簡単です。完全に解析されたアドレスは比較が簡単です。これは単純なデータ品質の問題かもしれませんし、複数のシェル会社が同じ配送先住所に大量の注文を行ったり、クレジットカードを使用して短期間で多くの分散した場所に配送する場合、コンプライアンスや信用に影響するかもしれません。

個別に保持されているフォーマットパーツは、現在のニーズに合った方法で組み合わせることができます。たとえば、長くて細い印刷ラベルが安くなった場合は、それらを使用するように再フォーマットできます。

もちろん、これらのいずれも特定のアプリケーションには適用できません。このタイプのデータは、収集されたときにソースで解析および検証することが、分析後よりもはるかに簡単です。そのため、YAGNIの場合でも、少しのコストと将来の大幅な節約のために、前もって余分な労力をかける方が良いかもしれません。

最後に、私は人的要因を却下しません。データモデルは、データモデラーによって作成されます。それは彼らがすることです。それが彼らの職業です。BLOBにダンプするように指示するつもりはありませんか？

出版会社でソフトウェアを開発するのに7年間費やしましたが、サブスクリプションリストの番地を解析することは、これまで取り組んだ中で最も困難な問題の1つでした。個別のフィールドにアドレスを分割するのに便利ですが、あなたは決して、できEVER人間の脳は考案することができるアドレス形式とコンポーネントのすべての可能な病理学的収差のために設計します。

すべての地域にはその癖がありますが、それは米国だけです。他の国で投げると、すべてのアドレスを解析したいすべてのアプローチのために非常に迅速に管理不能になります。ほんの2つの例：

スペインでは、ストリート番号は常にストリート名とカンマの後に続き、多くの住所には、1°や3ªなどのフロア番号の序数と、「左」の略語（「Izda」は、階段を上がる）、「正しい」（「Dcha」）またはその他の可能性。住所の歴史的慣習が異なるさまざまな国や地域の数に、その癖を掛けます...（日本？イギリスの田舎？韓国？中国？）

オレゴン州ポートランドには、都市をNW、NE、SW、およびSEの四分円に分割するNSおよびEW軸があります（Nの「四分円」ですが、私は脱線します）。NSストリートは、この軸から東と西に段階的に番号が付けられ、EWストリートのアドレスは、NSストリート番号が番号の「100ブロック」であると指示されます1123など）。米国住所のかなり標準的なもの。

頻繁に0205 SW Nebraska Stのようなポートランドの住所に出くわします。先行ゼロ？WTF？integer家の「番号」の列があります。

グリッドが設定されたとき、NS軸はウィラメット川によって定義されました。川の東側はすべて北東または南東であり、川の西側は北西または南西でした。都市が南に成長すると、川が東に蛇行するという不便な事実に遭遇したため、軸を南に投影すると、川の「西」側で軸の東にあるこの問題のある領域があります。解決策は、軸線から東に向かって数字が増加するように、先頭にゼロ、実際にはマイナス記号を追加することでした。

もし私があなただったら、究極のシステムを設計するという希望をあきらめるでしょう。すべての可能性を網羅することはできません。人類が以前に未開発の土地に押し込んだときに新しい可能性が生まれます。

米国の住所については、USPSが住所の標準化ですでに行ったことを確認し、house_number列をa にすることを忘れないでくださいvarchar。あなたはそれでいる間、あなたが解析しようとしている方法を見つけ出す1634 ENフォートレーンアベニューを。

残りの世界については、おそらく追加のフィールドを抽象化して、出現する可能性のあるものの80〜90％をカバーし、必要に応じて他のすべてを処理できる未解釈のフィールドのセットを提供しようとします。つまり、パーサーがアドレスの処理に失敗した場合、未解析のまま保存し、そのようなフラグを立てます。住所の解析に成功した場合は、さまざまなフィールドを見つけた順序を忘れないようにして、成果物に再組み立てできるようにしてください。

私は、最も重要な分野は郵便番号になると言っていましたが、それでも多くの場所で与えられていません。

がんばろう。これは楽しくて非常にイライラすることがありますが、正気の鍵は、いつ試行をやめ、入力を解析せずに保存するか、元の入力をバックアップとして部分的に解析するかを知ることです。

すべての設計質問のように、非常に適格な「依存する」ものがあります。データのストーリーに依存します。データの収集方法、使用方法、更新方法などです。すべてのコメントは、ハウツー回答ではなく、ディスカッションポイントとしてとるべきです。

あなた自身のためにアドレス検証サービスを構築しようとするよりも、アドレス検証サービスを使用するほうがより多くの恩恵を受ける可能性があるようです。費用はかかりますが、そのようなサービスの多くは大幅な郵送割引があります。

もちろん、特定のデータストーリーについては、ここで妥協点があります。解析された住所部分を保持し、結合された住所の計算列（列のセットである可能性が高い）を作成できます。これは実装に関する回答であり、通常の警告がすべて暗示されています。

解析されたアドレス設計を実装しました。これは、データ品質とデータ処理のニーズのために絶対に必要でした。しかし、それは物理的な住所、郵便住所、仮想住所などを持つビジネスでした。

発生する可能性のある他の問題は、異なる郵便サービスが異なる形式/注文/などで提示される同じ情報を必要とすることです。そのため、モデル化されたパーツを使用すると、さまざまな形式とレイアウトで同じ情報を表示できます。

最後に、国際的なデータをサポートするために国際的なビジネスを運営する必要はありません。米国に拠点を置く企業でさえ、国際アドレスをサポートする必要があります。あなたはそれを持っていないだろうと仮定することは大きなデータの間違いです。顧客は移動し、ベンダーは本社を変更します。ベンダーの連絡先情報は、米国に本社がある場合でも国際的なものになります。現在のシステムがその間違いを犯したとしても、これを先に進めたくありません。

Graham Rhindによる執筆とブログを強くお勧めします。彼は、あらゆる種類のアドレスとそれらに関連するトレードオフに関するデータ分野の専門家です。

_{*ここで述べたのは、大まかな一般化だけです。設計ソリューションにたどり着かなければならない質問が非常に多いため、数時間のチャットが必要になる場合があります。おそらくいくつかの写真といくつかのデータプロファイリングも。そして、住所に関する非常に風変わりなデータストーリーがたくさんあります。}

人々が提供する予測不可能な意味不明な意味を正しく解析するという大きな課題を完全に無視することで、解析の利点は、グループ化とソートの次元を提供することです。たとえば、郵便番号。ただし、特定のディメンションをグループ化または並べ替える必要があるまで、特定のディメンションを解析することによる利益はありません。

とにかく住所とは何ですか？あなたはそれが位置識別子であるという良いケースを作ることができますが、配達指示である「セメント工場から通りを下る」という等しく良いケースを作ることができます。オーストラリアでは、人々は郵便番号は場所の識別子であると考えていますが、そうではなく、ルーティングコード-配達指示です。4702はロックハンプトンメールセンターです。ロックハンプトンメールセンターは、海から300 km内陸の鉱山町エメラルドまでの地域にサービスを提供する主要な配送ノードです。

場所を特定する場合、BingとGoogleは、未解析の文字列からGPS座標に直接ジオコーディングできます。GPS座標は、未解析の文字列とともに小さなシンプルなテーブルに格納できます。一貫した良好な結果が得られる可能性のある唯一の一般的なアプローチを使用します：検証済み結果の巨大なデータベースとの重み付けされた部分一致のランク付け。

あなたが配達指示をしたい場合、あなたはまだよく、それが含まれている可能性があるため、未解析の文字列を維持することをお勧めしている何かを。

どちらの場合でも、未解析の文字列を保持することをお勧めします。なぜなら

• それはそれ自体で有用です
• いつかあなたはそれを解析する方法を見つけます
• 数日後、あなたはそれを正しく解析する方法を見つけます
• これは終わらない

おそらく、住所は常に配達指示であり、少なくとも 1つの場所識別子が含まれています。「123 Main st、Emerald 4702」宛の手紙には、エメラルドのロックハンプトン北部のRMCと番地の3つの場所がエンコードされています。ロックハンプトン郵便局は、RMCに送信します。RMCはそれをエメラルド郵便局に送信し、エメラルド郵便局は123メインストリートの場所を知っていることを願っています。

オランダではありますが、私は以前にこのようなシステムを実装しました。実は、この種の情報は、あなたが考えているよりも多くの方法で変化する可能性があります。通りの名前が変更され、都市がマージされます。アドレスを単一の文字列として解析せずに、そのような情報を更新できると便利です。

郵便番号/郵便番号、建物名、道路名を分離することは理にかなっています。しかし、その後「line」、「area」などを追加し始めると、line1、line2などと比較して疑問が生じます。問題は、私と妻でさえ、私たちが住んでいる町の名前に同意できないことです！「村」の名前は町の畑に入れられるのですか、それとも道路の名前の下の行に入れられ、地方の都市は町の畑に入れられますか？（町ではなく村に住んでいる場所を呼ぶと気分を害する人もいれば、村ではなく町と呼ぶと同じ場所に住んでいる他の人が気分を害する！）

したがって、おもしろいことをしようとすることは、使用している住所確認システムと同じです。しかし、それはさらに悪化します。英国では、すべての住所に郵便番号が必要ですが、家が建てられてからしばらく経つまで郵便番号は割り当てられません……だから、システムは住所に関するすべての規則を破る必要があります！

他の回答ですでに言及されている問題に加えて、一部の言語、特にゲルマン語では、通りの名前は複雑になる傾向があります。たとえば、ドイツの多くの町/都市では、鉄道駅に通じる「Bahnhofstrasse」（「Bahnhof」は鉄道/駅を意味し、「Strasse」は通りを意味する）を持つことが一般的です。確かにこれらの2つのコンポーネントを分離することはできますが、それらを（プログラムで）一緒に戻したい場合は、偏りの問題になります。

または、「ロマンス」またはラテン語の言語では、「Rue de la Pais」または「Boulevard desChamps-Élysées」という形式のストリート名を頻繁に使用します。これで、前置詞（「de」）と定冠詞（「le」または「la」）が混在しました。これらは結合されます。それらはストリートタイプまたはストリート名の一部を表していますか？（おそらくどこかに保存する必要があります。そうしないと、再び偏角になります。）

私はかつてこのようなものをモデル化しました。しかし、それは中規模の大学（米国）の居住用資産管理事務所にとっては非常に小さなアプリケーションでした。次の理由により、アドレスを非常に細かくしました。

• 同じ名前の街路がありましたが、街路の「タイプ」が異なります（「Woods Avenue」と「Woods Court」など）。
• ユーザーは、メンテナンス作業を最適化したいと考えていました。たとえば、同じブロックに複数のサービスリクエストがあった場合、それらを同時に処理できます。
• ユーザーは、同じ建物内の異なるユニット（アパートメント）間の問題を相関させることを望んでいました。たとえば、複数のアパートが寒さや不十分な温水を報告した場合です。

...そして、私がもう覚えていない他の理由。（これは1980年代後半でした。）

繰り返しますが、これは理にかなっていますが、それは、対処するアドレス（およびアドレスのフォーマット規則）がかなり少ないためです。他の回答で既に述べた理由により、このアプローチが米国の住所に限定されていても規模が拡大するとは思わない。