データベース設計親子表対複数表

Question

country-state-city-headの親子関係を作成しようとしています。私は2つのapproaches- 1）は、単一のテーブル -

 
pk| name    |  type  |  parent 
    1 | US    |  country  |  null 
    2 | UK    |  country  |  null 
    3 | California  |  state  |  1 
    4 | Los Angeles  |  city  |  3 
    5 | Kent    |  state  |  2 
    6 | Obama    |  president |  1 
    7 | Cameroon   |  pm   |  2 

状態/都市/国のために一定期間にわたる人口増加を記録します別のテーブルを参照します。このテーブルの主キーを作成して検討します。

2）2番目のアプローチは、国、州、頭部および都市の複数のテーブルを作成し、 リレーションシップに外部キー参照を使用することです。 各テーブル（市/州/国）の主キーが人口増加テーブルを参照します

1に近づくと2以上の利点がありますか？クエリする方が速いのですか？

Answer 1

アプローチ1はEAVテーブルであり、事前に必要なフィールド（さまざまな医療検査から保存する可能性のあるさまざまなものをすべて定義するなど）を絶対に予測できない限り、ほとんどの場合最悪の選択です。変更の対象ではない地理的データについては、私はペストのようなオプション1を避けるだろう。それは照会するのが難しく、ブロックのための競合の源になり、一般的にはちょっと悪い考えです。

リレーショナルデータベースは、リレーショナル形式で設計するときに最も効果的です。オブジェクト指向の考え方を使用してデータベーステーブルを定義しないでください。 EAVの機能が本当に必要な場合は、少なくともそのようなことに最適化されたnoSQlデータベースで実行してください。

Answer 2

私は、それがデータベースに保存したいものがあれば、それに依存すると思います。たとえば、他のエンティティの「首都」などの国固有のデータを保存する場合は、アプローチ2を使用します。ただし、「集団グループ」を表す必要がある場合は、1がうまくいくようです簡単です。あなたの親のidフィールドは外部キーでなければなりません。つまり、同じテーブルの親のpkです。あなたがメインテーブルの文字列ではなく数字として格納できるように、タイプテーブルに外部キーをタイプすることを検討します。あなたのキーがインデックスされている限り、あなたはパフォーマンスに大きな違いがあるとは思わないでしょう。

Answer 3

構造が剛性の場合は、アプローチ2を参照してください。参照統合を正確に定義できるため、状態が国の親である（たとえば）逆に）。

動的にに「ノード」（例：地域または地方自治体）と他の種類の関係を追加すると予想される場合（たとえば、いくつかの国には州がないため、都市は直接「下」の国）、アプローチ1の追加された柔軟性は、参照整合性の「薄さ」を正当化するかもしれない。

正しく実行されていれば、どちらのアプローチもパフォーマンスに似ています。