sql - 都市/州が不明な場合に顧客を国にリンクする方法

Question

Customers、Countries、States、および Cities という名前のデータベース テーブルがあるとします。個々の顧客には、Cities テーブルにリンクする CityID フィールドがあります。各都市には StateID フィールドがあり、これは州テーブルにリンクされており、国についても同様です。

顧客の完全な住所がわかっている場合、これはすべて簡単ですが、国しかわからないこともあれば、州しかわかっていないこともあります。私たちは常に都市を持っているわけではありません。

これをどのように処理しますか？私たちは国を救いたいと思っていますが、都市を知らなければできません。

顧客テーブルに StateID フィールドと CountryID フィールドを追加することもできますが、これは設計が不十分なようで、データの一貫性が失われる可能性があります。

誰でも何か提案はありますか？これはかなり標準的な質問だと思いますが、良い答えが見つかりません。

PS 以下の Jaffar のコメントへの回答として、これを行う理由は、顧客がどこに分散しているかを分析する必要があるためです。クライアントは非常に高価な医療用スキャナーを病院グループに販売しており、注文時にどのサイトがスキャナーを受け取るかを常に知っているわけではありません。したがって、可能な限り多くの情報を指定できるようにする必要があります。それは、国のみ、州、都市などです。

現在、これを行う必要があるのは米国のみですが、クライアントが分析を他の国に拡大したい場合に備えて、柔軟なアプローチを提供したいと考えています.

Answer 1

データ モデル パターン ブックを見ると、それらが地政学的領域を抽象化していることがわかります。

テーブル継承を使用します。

国は地理的領域を拡張し、州/県、郡、市も同様に拡張します (ただし、郵便番号や大陸は拡張しません)。

外部キーを持つ 1 つの列を使用して、任意の地理的領域に顧客を向けることができるようになりました。都市を指すと、州、国を導き出すことができます。それを国に向ければ、少なくともその国を知っていることになります。

これは、郡、州、国ごとに税率を追跡するのにも役立ちます。

Answer 2

リチャードが示唆したように、私はdba.stackoverflow.comで質問しましたが、質問の仕方は少し異なりました。私は 3 つのテーブル アプローチ (Richard が好む)、自己参照 Locations テーブル アプローチ (クエリが複雑になるだろうと思った)、3 つのテーブルを使用する Juhana のアプローチ、ただし空白のエントリ (これには私には一番簡単に思えた）。

そこにある 2 つの返信 (完全に見たい場合はリンクをたどってください) に従って、自己参照 Locations テーブルのアプローチを試してみたところ、思ったよりもはるかに簡単であることがわかりました。すべてのアプローチの中で最も柔軟性が高く、まだ考慮されていない追加のレベルを含め、任意のレベルのリージョンにリンクでき、顧客テーブルから複数のリンクを必要とせず、複雑なクエリを必要としないためです。

純粋な SQL データ アクセスでこのアプローチを使用するのが簡単かどうかはわかりませんが、ORM を使用しているため、子の場所がエンティティのコレクション プロパティとして具体化され、ナビゲーションが非常に簡単になりました。

返信してくれたみんなに感謝します。これが他の誰かに役立つことを願っています。

Answer 3

都市の名前が空の場合は、都市テーブルで州ごとに 1 行を作成し、都市と州が空の場合は国ごとに 1 行を作成します。都市または州が不明な場合に使用します。