ForiegnキーYAHかいや

Question

非F-KのSCHEMA

human 
    human_id | name 

alien 
    alien_id | name | planet 

comment 
    comment_id | text 
     1   hello 

vote 

    to_id | to_type | who | who_type 
    1  human  1  alien 
    1  comment 1  human 

FK-SCHEMA

human 
    human_id | name 

alien 
    alien_id | name | planet 

comment 
    comment_id | text 
     1   hello 

entity_id 
    entity_id | id | type 
     1  1  human 
     2  1  comment 
     3  1  alien  

vote 

    to_id | who_id 
    1  3  
    2  1 

私が優れている1お聞きしたいですか？

まず一つはなしで、外部キー

私が挿入二回行う必要があるとunnecesaryを得るために参加するよう

2つ目は遅くなり、外部キー

イマイチ（FKキー付き）は、第2の1であります人間/外国人の名前など

entity_idが最大で18446744073709551615に達したらどうなりますか？

Answer 1

スーパータイプを追加してHumanとAlienを統合し、このスーパータイプをリレーションシップで使用することをお勧めします。私はまた、ユーザーの投票からのコメントの投票を別々の関係に分けることを提案します。以下の表を考えてみましょう：

やや単純化が、これは、基本的な考え方です。これは、ユーザーが人間とエイリアンの両方の詳細を持つことができます。必要に応じて、いくつかの追加の列とトリガーを使用して、互いに素なサブタイプを適用することができます。

外部キーと結合が遅くなるかどうかを確認します。冗長な関連付けが排除されるので、正規化されたデータベースがより効率的である可能性が高いという議論ができる。実際には、パフォーマンスは、結合を避けるよりも、インデックスの効果的な使用とはるかに関連しています。

auto_incrementカラムがオーバーフローした場合、データベースエンジンはエラーを返し、さらに多くの行を挿入することを拒否します。この場合、より大きなタイプを使用するように列を調整することができます。 MySQLで最大の型の領域を超えると、おそらく別の（あるいはカスタム）ソリューションになるでしょう。