国-州-市長の親子関係を作成しようとしています。2つのアプローチを検討しています-1）単一のテーブルを作成します-
pk| 名前 | タイプ | 親 1 | 米国 | 国 | ヌル 2 | イギリス | 国 | ヌル 3 | カリフォルニア | 状態 | 1 4 | ロサンゼルス | 都市 | 3 5 | ケント | ケント | 状態 | 2 6 | オバマ | 社長 | 1 7 | カメルーン | カメルーン 午後 | 2
このテーブルの主キーは、州/市/国の一定期間にわたる人口増加を記録する別のテーブルを参照します。
2) 2 番目のアプローチは、国、州、首長、および都市に対して複数のテーブルを作成し、関係に外部キー参照を使用することです。次に、各テーブル（都市/州/国）の主キーは、人口増加テーブルを参照します
アプローチ 1 には 2 よりも利点がありますか? クエリの方が速いですか？
アプローチ 1 は EAV テーブルであり、事前に必要なフィールドを完全に予測できない場合 (さまざまな医療検査から保存したいさまざまなものをすべて定義するなど) を除いて、ほとんどの場合、最悪の選択です。変更される可能性がそれほど高くない地理データの場合、疫病のようなオプション 1 は避けます。クエリが難しくなり、ブロッキングの競合の原因となり、一般的には悪い考えです。
リレーショナル データベースは、リレーショナルな方法で設計されたときに最適に機能することを忘れないでください。データベース テーブルの定義にオブジェクト指向の考え方を使用しないでください。EAV 機能が本当に本当に必要な場合は、少なくとも、そのようなことに対してより最適化された noSQl データベースで実行してください。
構造が厳格な場合は、アプローチ 2 を使用します。これにより、参照整合性を正確に定義できるため、(たとえば) 州が国の親であるという状況が発生することはありません (その逆ではありません)。
一方、他の種類の「ノード」(州の下にある地域や地方自治体など) や他の種類の関係 (たとえば、州がまったくない国もあるため、都市は国の下にある必要があります) を動的に追加することが予想される場合は、 、そしてアプローチ1の追加された柔軟性は、参照整合性の「脆弱性」を正当化するかもしれません。
正しく行われれば、どちらのアプローチもパフォーマンス的にはほぼ同じように動作するはずです。