私は、他の "値テーブル"からの値にリンクされた多くのフィールドを持つテーブルがあるとしましょう。当然のことながら、私は、整合性を徹底するために、それぞれの外部キーの制約とその逸脱を宣言します。テーブルに多数の（20 +以上の）外部キー制約がある場合、それは欠点ですか？
最終的に20から30の範囲でこのようなフィールドの数を取得するとどうなりますか？それはどういうわけか、テーブル操作を "遅くする"かどうかですか？
ADDED：値テーブルのレコード数はわずかです（通常は5-10など）。データベースはSQL Server 2008です。
外部キーが1つあると、挿入/更新操作が外部キーをゼロにするのに対して、外部キー値が実際に存在するかどうかを確認する必要があるためです。 30個の外部キーを持っていると遅くなり、それがない。
あなたのバリューテーブルやデータベースエンジンのサイズやインデックスなどを含め、多くのものに依存しますが、最良のケースのシナリオではほとんど無視されるかもしれません。
はい、関連するすべての制約がチェックされているため、挿入と更新にいくらかのパフォーマンス上のペナルティがありますが、データを高速に挿入しようとしない限り、問題は起こりそうにありません。通常、データが迅速に処理されるのではなく正確に維持されることがより重要であるため、ペナルティは発生する価値があります。
いくつかの列の更新を実行すると、それらの列の制約のみをチェックする必要があり、ほとんどのDBMSはその制約をチェックします。
SELECT文の実行速度が極端に低下することはなく、一部の（おそらくまれな）ケースでは、結合されている2つの表の間の外部キー関係をオプティマイザが認識することによっても利益を得ることができます。
子テーブルに行を挿入すると、DBエンジンは親テーブル内の対応する値が存在するかどうか検索します。これにより、CPUと論理読み取りが使用されます。親テーブルが小さい場合は、キャッシュに格納されている可能性が高いため、杖が暖かいとすぐに物理的に読み取りが遅くなることはほとんどありません。
親テーブルから削除する場合は、子テーブルに対応するインデックスがない場合、子テーブル全体がロックされてスキャンされます。一方、すべての外部キーに対応するインデックスがある場合、最大20-30の追加インデックスが子テーブルに追加される可能性があります。これはかなりの減速です。
独自のベンチマークを実行して自分自身で確認したい場合があります。
20-30フィールドのうち、ほとんど何が使用されませんか？他のテーブルを作ることができるかもしれません。コーディングの観点から2つのテーブルを更新しなければならないのは難しくなりますが、ほとんどの場合、2つ目のテーブルを更新する必要がない場合は、処理が高速になります。
私は自分のフィールドを設定できる対応する「カスタム」テーブルを持つメインテーブルを持つサードパーティのアプリケーションを扱います。残念ながら、私たちはいつも 'カスタム'フィールドを使用し、メインテーブルを扱うだけではほとんど逃げることはできません。
あなたのクエリが制約を使用しているかどうかは、依存していると思います。制約のためにクエリが別のテーブルをチェックする必要がある場合は、パフォーマンスヒットが表示されます。クエリで制約の列が参照されない場合、パフォーマンスヒットは無視される可能性があります。
ほとんどすべてのデータベース設計と同様に、これは依存しています。'あなたのアプリケーションが重いを挿入、更新、削除するとパフォーマンスの問題が発生します。これは、特に 'value'テーブルが変更されていない場合、正規化解除が正当化される場合があります。