住所のデータベース正規化

Question

私はリムジン会社のデータベースを構築しようとしていますが、顧客、運転手、系列会社、受注に関連する住所の正規化の程度につきまとうことがあります。

基本的にはアフィリエイトやドライバのアドレスは次のようになります。 address_line_1、address_line_2、市、州、郵便番号、国

私の問題は、注文と顧客のアドレスから来ています。 address_line_1、address_line_2、市町村、州、郵便番号、国、address_type_1（自宅、ビジネス）、address_type_2（ピックアップ、ドロップオフ - これは注文にのみ含める必要があります）のようになります。

すべての4つのテーブルの間には、顧客と注文表が異なる2つのフィールドを除いて、アドレスフィールドに類似点があります。

すべてのレコードは一意のIDで識別されることに言及する必要があります。 例：

カスタマーID - 万 - 99,999

注文ID - 10万 - ノーリミット

ドライバーID - A1 - A999（多分）

アフィリエイトID - 千 - 9999

これは単なる例であり、理解するのに多くの時間を費やさないでください。

正常な正規化データベースを作成するには、いくつのアドレステーブルを使用する必要がありますか？

1. 一つのアドレステーブルのすべてのフィールドが含まれてプラスアドレスのタイプ（顧客、注文、アフィリエイト、ドライバ）を記述し、余分な1：現時点で

   は、私は私の心の中で3つのアイデアを持っています。これは本当に好きではありません。

2. 2つのアドレステーブル。 1つは運転手と系列会社、もう1つは顧客と受注です。 2番目のテーブルの場合、私は持っていて、フィールドは常に顧客のためにNULLになります。これも好きではありません。

3. 3つのアドレステーブル。 1つは運転手および系列会社、1つは顧客、もう1つは注文です。未使用のフィールドは、これが他の2つのフィールドよりも良い選択肢であると思うようになります。

これらの3つのオプションに関するアドバイスはありますか？

ありがとうございます。

UPDATE：

は、テーブルのIDの番号制度についてはまだ気にしないでください。それはほんの一例でした。私はまだ最高のナンバリングシステムを理解する時間がなかった。一度私の住所の問題を整理してしまうと、そのことに気づくでしょう。

マットの答えから、私はドライバーを残して、住所を含むテーブルをアフィリエイトして、顧客と注文表を何とか並べ替えてしまいます。

お客様には、簡単なアクセスのためにプロファイルに保存したい複数のアドレス（家、ビジネス1、ビジネス2、好きな場所など）を持つことができるため、アドレステーブルが必要です。

問題の方程式を少し変えるかもしれない注文表について言及するのを忘れました。 ご注文の際には、PICK-UPとDROP-OFFの場所が必要です。しかし、これは住所（番地）または空港のいずれかになります。これは、番地に関連するフィールドが空港固有のフィールドと一致できないことを意味します。だから、テーブルの中に4つの実体（pu_address、pu_airpot、do_address、do_airport）を持つことは、私のスペースを浪費し、プログラミングの混乱を招くことになると確信しています。 例：ピックアップフィールドの場合は ：Address_type、Address_line_1、...、州、国、空港、航空会社、Flt番号、... とピックアップと同じものが落ちます。

私はまだ進む方法についてわからないOrderテーブルにはまだ問題があります。余分なテーブルの有無にかかわらず、住所と空港のピックアップとドロップオフの両方の場所を含める必要があります。

更新 ありがとうございました。まず、別のフィールドにアドレスを格納します。問題はまだ注文のために残る。私はどのタイプのpuについての例を挙げ、リムジンサービスを利用します。住所：123 Main St、Chicago、Il、60640;空港：ORD、AA、123.これらのフィールドを何らかの形でテーブルに統合する必要があります。

オプション： 受注テーブル

ORDER_ID、空港やフィールドをアドレスの両方を持っている必要があります...、ピックアップフィールド、両方の空港アドレスフィールドとドロップオフフィールド。

このオプションはまだ正しいとは言えません。

次は2つの余分なテーブルを持つことです。 1つはアドレス（ピックアップまたはドロップオフを認識するためのフィールドを含む）用です。他の1つは空港のためのものです（puのフィールドまたはdoのフィールドもあります）。

注文記録のみの情報を取得するために2つのクエリを実行する必要があるため、このオプションも嫌いです。最初に注文情報を取得し、ピックアップとドロップオフのタイプ（空港または住所）を知った後、特定のピックアップとドロップオフ情報を取得するために別のクエリを実行します。

だから私は間違っていますか？私は何かが恋しいですか？

はい、確かにいくつかの検証システムを使用して、アドレスが正しいことを確認します。

Answer 1

私は実際にアドレスを処理して住所を処理する専門家であるSmartyStreetsで実際に作業しています。私の経験では、あなたのようないくつかの状況を見てきました。

私は当初、それが記録のタイプに基づいてあなたのセグメンテーションID番号に関係しています。 4種類のレコード（顧客、運転手、系列会社、受注）が異なるテーブルに格納されている場合、なぜID範囲の制限が必要ですか？ （更新：これは手元の主な問題ではありません...）

ここではデータベース設計について少し説明します。理想的には、デザインには、アドレスデータに結合することなく、コアドメインの操作（つまり、顧客、注文、ドライバなどの調整）を反映させる必要があります。アドレスは重要であるかもしれませんが、あなたのビジネスの中核操作ではありません。この地面と元の投稿から収集したものから、私はすぐに実際の記録とは別に住所を保存することを躊躇します。

各テーブルに同じようなフィールドがありますが、それらは異なるビジネス目的を表しており、未使用の不要なフィールドのリスクはありません。質問はそれほど多くの "どのようにアドレステーブルを作成する"ではありませんアドレスのテーブルのみを作成することの質問です。

住所にはさまざまな形や形がありますが、リムジン会社が正しい住所情報を持ち、データベースを正規化することが重要です。 USPS（あなたが米国にいると仮定します）は、特定のベンダーがアドレス正規化サービスを提供することを証明しています。これはCASS ™認証と呼ばれています。各アドレスをCASS ™サービスで実行すると、完了です。アドレスは同じように見え、完全な情報を持っており、配送可能でもあります。私は、LiveAddressのようなもので検索を開始することをお勧めします。これはポイント・オブ・エントリーのアドレスを確認します。CASS list scrubbing serviceは一度にバッチのアドレスを確認します（重複を警告します）。

更新：いくつかのアドレスの場合、顧客が持っている可能性がありますが、別のテーブルを使用することをお勧めします。しかし、あなたはまだCASSで標準化/検証したいので、必要に応じて後で複製を引き出すことができます（実際にはアドレスが実際に存在することがわかります）。

それ以外の場合は、各アドレスを関連付ける実際のレコード（別々のテーブルではない）にインラインで格納することを検討してください。

さらなる質問や指示については、私は個人的に手助けすることができます。空港からアドレスを分離について

UPDATE

：それは潜在的にあなたのビジネスニーズに応じて、有効な違いですが、空港があまりにも、アドレスを持っていることを覚えておいてください。テーブルにフィールドを追加して、住所が指している会社名や所在地（「オヘア国際空港」など）を保存することができます。これにより、いくつかのフィールドを統合することができます。また、住所（ストリート、市、州、郵便番号など）別のフィールドにアドレスを保存することをお勧めします。

Answer 2

今では遅すぎる、おそらくですが、これは標準の正規化ルールに従うだろうと私は1つのAddressesテーブル（AddressTypesテーブルにaddress_id、address_line_1、address_line_2、city、state、zipcode、country、address_type（FK））をお勧めします。 Ordersテーブルには、Addressesテーブル（pickup_address_idおよびdelivery_address_id）との2つの外部キー関係があります。 Customers,DriversおよびAffiliatesテーブルの設計に関する質問がありますが、正確にどのように関係しているのかをよく理解していないと、ソリューションを処方するのが難しいです。スーパータイプ/サブタイプ関係を作成します

一つの選択肢（それはあなたのための右の1である場合、私は知らない）Partiesテーブルを持っているだろう（party_id、party_type）（への1対1またはゼロでいずれの場合もPartyのタイプのCustomers,DriversおよびAffiliatesである。データモデリングに関するDavid C. Hayの記事を読んで、理解を深めることをお勧めします。