テーブルが次のようになっていると仮定して、これは良いデザインなのだろうかと思っていました
ADDRESS(id, address, city_fk, stateFK, countryFK),
CITY(id, name, stateFK, countryFK),
STATE(id, name, countryFK),
COUNTRY(id, name)
country fk が 3 つのテーブルで繰り返されていることに注意してください。2つのテーブルでfkが繰り返されている状態ですか？これが良いデザインかどうか誰か教えてください。もしそうなら、なぜですか？なぜなら、私はそれを頻繁に繰り返す必要があるとは思わない.
乾杯
あなたはこのようなものがもっと欲しい：
それが私だったら、フィールドの名前を少し変更します。
私はその道を進むかどうか確信が持てません。国テーブルと確かに州テーブルがあることは理解できますが、都市が問題の特定の国/州に属していることを保証する都市テーブルがあります。あなたの City FK テーブルに必要なデータの量は膨大になるだろうと想像するだけですが、そのメリットが見られるかどうかはわかりません。おそらく、都市のテーブルを持つことから得たいと思っている利点をもう少し詳しく説明していただければ、私はこれにうまく答えることができるかもしれません. 私が見たほとんどのシステムには国と州の FK テーブルがありますが、これらのテーブルは必ずしも互いに関連しているわけではありません。
私の質問は、「何のための良いデザインですか？」ということだと思います。アドレスの正確な整合性が設計にとって絶対に重要である場合、これは実りある議論の始まりとなる可能性があります。一方、目的がアドレスを収集し、実際のユーザーから得られると予想されるあらゆる種類のアドレスを格納できるようにすることである場合は、もう少し柔軟性のあるものを検討することができます。 UI のわかりやすい検証ルールのセット。
正規化しすぎていませんか？
繰り返されるデータのコストを削減している間、アドレス全体を取得するために3つまたは4つの結合を要求することによって、データを否定している可能性があります...
個人的に私は固執します：
住所：
もちろん、市/州/郵便番号/国などのインデックスを作成する必要がありますが、複数のテーブルに参加するよりもはるかに高速になる可能性があります。
（注：私はDBAではないため、クレームをバックアップすることはできませんが、これは私が使用しているものであり、正常に機能します）
私はこれを行います：
では、異なる都市、州、国で同じ住所を持つ確率はどのくらいか教えてください。最小限。したがって、これは機能するはずです。DB を極端に正規化しても、常に機能するわけではなく、役立つわけではないことに注意してください。
お役に立てれば
よろしくお願いします！
すべてのテーブルで PrimaryKeys をどのように定義したかによって異なります。すべてのテーブルのキーとして列がある場合は、idすべてのテーブルの列を減らして、FK を次のリージョンに保持するだけにすることができます。
address(与えられた)city address.city_fk 経由statecity.state_fk経由countrystate.country_fk 国経由デザインはクリスのようになるでしょう。1 つのクエリですべてのデータが必要な場合は、結合を行います。
ただし、idすべてのテーブルでキーではなく部分キー (データセットを単独で定義できない) である場合、これは適切な設計であると考えられます。アドレスは次のように識別されます。
「City 23」を知っているだけでは十分ではありません。なぜなら、どの州の 23 番目の都市で、どの国のどの州であるかという疑問が生じるためです。これにより、すべてのテーブルにデータを格納する必要があります。
ただし、キーをどのように定義したかによって異なります。
考慮してください: 私が州を知っていて、州の FK が国である場合、私は国を推移的に知っており、それを再び含めることは冗長な非正規化です。
私が都市を知っていて、都市の FK が州である場合、私は推移的に州を知っており、それを再び含めることは冗長な非正規化です。
つまり、都市がわかれば、州もわかり、国もわかります。
ADDRESS(id, address, city_fk), CITY(id, name, stateFK), STATE(id, name, countryFK), COUNTRY(id, name)
実際には、都市をエンティティまたは属性にすることには正当な議論があります。郵送先住所のようなものについては、おそらく属性にする方が簡単です。
「有権者ファイル」(選挙や政治キャンペーンに使用されるデータベース) のようなものでは、都市をエンティティにするのが理にかなっているかもしれません。これは米国バージニア州で特に重要です。この州は、ほとんどの都市が郡に属している米国の他の地域とは異なり、法人化された都市が独立した政治管轄区であるという点で米国ではユニークです。
バージニア州以外の州でも、カウンティの一部である都市では (市長と評議会の) 選挙が別々に行われるため、政治データベースでは、都市を (さらに小さくなり、ワードと地区、タウンシップと村を作り、大きくすることで) 便利です。 、郡と HD、SD と CD) をエンティティに変換します。
たとえば、米国オハイオ州のレイクウッドを見てみましょう。管轄区域では、レイクウッドはカヤホガ郡です。政治的なテレビ広告に関しては、クリーブランド、アクロン、カントンのテレビ指定マーケット エリアの一部です。クリーブランド市のすぐ外にあり、管轄区域でもカヤホガ郡の一部です。レイクウッドは 4 つの評議会区に分かれており、各区は 15 以上の地区に分かれています。レイクウッドとクリーブランド市の西側の一部を含む州議会議事堂第 13 地区の一部です。州上院第 23 区の一部であり、ブルックリン、ブルック パーク、クリーブランド (第 7 区から第 21 区および第 14 区の一部)、レイクウッド、リンデール、ミドルバーグ ハイツ、パルマ、パルマ ハイツを含んでいます。レイクウッドは、オハイオ州の第 10 連邦下院選挙区 (デニス クシニッチが代表) にあります。
では、オハイオ州の任意の有権者について、投票時に誰が投票用紙に載っているかをデータベースでどのように表すのでしょうか?
テーブルの設計に関して私が常に行っていることは、テーブルを見て、どのような問題が発生する可能性があるか (つまり、どのような矛盾が生じる可能性があるか) を突き止めることです。
あなたの特定のケースでは、明らかなことは、ワイオミング州と崩壊状態にあるダラス市にある住所を作成できることです。おっと、テキサスを意味します:-)
同様に、オーストラリアの国とテキサス州 (米国内)および南アメリカのペルーの Xolotllotl 市にある住所を持つことができます。郵便配達員があなたを追跡するときに、あなたのスキーマを説明する必要はありません.
それをどのように解決しますか？おそらく、住所から都市を参照し、都市から州を参照し、州から国を参照する必要があります。
しかし、住所は厄介な獣であり、住所がとる形式は住所がどこにあるかによって大きく異なります。郡を持っているものもあれば、州の境界をまたいでいる市もあります。
特定の都市で人を探す必要がない限り、私はそれを自由形式の住所に組み込みます (ほとんどの場所には何らかの郵便番号があり、そのほうが適しています)。州または国ごとに選択したい場合は、それらを別のフィールドのままにしておきます。
私の最初の試みは次のとおりです。
ADDRESS(id, address_including_city, stateFK),
STATE(id, name, countryFK),
COUNTRY(id, name)
異なる国の「同一の」州を区別する必要がありますが (たとえば、ワシントン州と西オーストラリア州はどちらも西オーストラリア州です)、データ入力画面で国を簡単に表示して、オペレータがどの州に入るかを知ることができます (または、より可能性が高い)。 、彼らは最初に国を選択し、州の選択は絞り込まれます)。
私が知る限り、 Xolotllotl は実際の都市ではありません。昔の美しいインカの名前のように聞こえる、私が作り上げた都市の 1 つです。