他の「値テーブル」の値にリンクされた多くのフィールドを持つテーブルがあるとしましょう。当然のことながら、完全性を確保するために、それぞれに外部キー制約を宣言します。
最終的にそのようなフィールドの数が 20 ～ 30 の範囲になったらどうしますか? どういうわけかテーブル操作を「遅く」しますか、それとも実際にはそうではありませんか?
追加: 値テーブルには、通常 5 ～ 10 程度の少数のレコードしかないと予想されます。データベースは SQL Server 2008 です。
6 に答える
2
子テーブルに行を挿入すると、DB エンジンは、親テーブルに対応する値が存在するかどうかを調べます。これにより、CPU と論理読み取りが使用されます。親テーブルが小さい場合、それらはキャッシュ内にある可能性が高いため、杖が温まるとすぐに多くの遅い物理読み取りが予想されることはありません。
さらに懸念されるのは、親テーブルから削除する場合です。子テーブルに対応するインデックスがない場合、子テーブル全体がロックされ、スキャンされます。一方、すべての外部キーに対応するインデックスがある場合、子テーブルに最大 20 ～ 30 個のインデックスが追加される可能性があり、これはかなりの速度低下です。
独自のベンチマークを実行して、自分の目で確かめてください。
于 2009-07-15T20:50:28.827 に答える
1
はい、関連するすべての制約がチェックされるため、挿入と更新にパフォーマンスの低下がありますが、データを高速で挿入しようとしない限り、問題が発生する可能性はほとんどありません。通常、データを迅速に維持するよりも正しく維持することが重要であるため、ペナルティを課す価値は十分にあります。
いくつかの列のUPDATEを実行する場合、それらの列の制約のみをチェックする必要があり、ほとんどのDBMSはそれらの制約のみをチェックします。
もちろん、SELECTステートメントの速度が低下することはなく、場合によっては（おそらくまれに）、結合されている2つのテーブル間の外部キー関係をオプティマイザーが認識していることでメリットが得られることもあります。
于 2009-07-15T20:31:32.297 に答える
1
データベースが外部キー値が実際に存在することを確認する必要があるため、外部キーが1つあると、外部キーが0の場合に比べて挿入/更新操作が遅くなります。30 個の外部キーがあると、ない場合よりも遅くなります。
とはいえ、どれだけ遅くなるかは、値テーブルのサイズ/使用しているデータベースエンジン/インデックスなど、多くのことに依存し、最良のシナリオでは実質的に無視できる場合があります.
于 2009-07-15T20:23:25.930 に答える
0
20〜30のフィールドのうち、めったに使用されないフィールドはいくつありますか？たぶん、他のテーブルを作成することもできます。コーディングの観点から2つのテーブルを更新する必要がありますが、ほとんどの場合2番目のテーブルの更新を省略できると、処理が高速化されます。
私は、独自のフィールドを設定できる対応する「カスタム」テーブルを備えたメインテーブルを持つサードパーティアプリを扱っています。残念ながら、私たちは常に「カスタム」フィールドを使用しており、メインテーブルを処理するだけでうまくいくことはめったにありません。
于 2009-07-16T01:53:36.090 に答える
0
クエリが制約のいずれかを使用しているかどうかに依存すると思います。制約のためにクエリで別のテーブルをチェックする必要がある場合は、パフォーマンスが低下します。クエリが制約内の列を参照していない場合、パフォーマンスへの影響はおそらく無視できます。
于 2009-07-16T02:02:06.143 に答える
0
データベース設計に関連するほとんどすべてのように、これは「依存します」。アプリケーションで大量の挿入、更新、削除を行うと、パフォーマンスの問題が発生します。これは、特に'value'テーブルが変更されていない場合に、非正規化が正当化される可能性がある場合です。
于 2009-07-16T02:02:33.553 に答える