住所を個々の列に分割すると、どのような問題が解決しますか？
ソフトウェア開発者向けにテーブルとリレーションを設計するチームがあります。私たちの組織では、彼らは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の質問：閉じられた良いアドレスパーサーはどこにありますが、アドレスの解析がどれほど難しいかを示しています。 私が彼らの設計決定をよりよく理解し、アイデアでクライアントを売るために... 住所を個々の列に分割すると、どのような問題が解決しますか？ 問題が発生したため、このようなシステムを実装した人にとってのボーナスポイント。