質問

FK(外部キー)を考慮する必要があるデータベースを設計しています 制約。しかし、それに限定されません 正式な構造化と正規化。 何かを提供する場合にのみ、 パフォーマンスまたはスケーラビリティの利点。

私はいくつかの興味深い記事を読んで、実用的な利点を求めてグーグルで調べました。リンクは次のとおりです。

http://www.mssqltips.com/tip.asp?tip=1296

(正式な構造化と有名なカスケード削除\更新を除いて)FKの利点についてもっと知りたいと思いました。

  • FKはデフォルトでは「インデックス付けされていない」ので、FKをインデックス付けする際の考慮事項は何ですか?

  • 外部キーとしてマップされるnull許容フィールドの処理方法-これは許可されますか?

  • インデックス作成とは別に、これはSQL-Serverでのクエリ実行プランの最適化に役立ちますか?

他にもあることは知っていますが、これについて話す専門家の方がいいと思います。案内してください。

役に立ちましたか?

解決

  • 外部キーは、パフォーマンスやスケーラビリティの利点を提供しません。
  • 外部キーは参照整合性を強制します。これは、誰かがエラーで親テーブルから行を削除しようとした場合にエラーを発生させることにより、実用的な利点を提供できます。
  • デフォルトでは、外部キーはインデックス付けされません。親行を削除/更新するときに子テーブルのテーブルスキャンを回避するため、外部キー列にインデックスを付ける必要があります。
  • 外部キー列をnull可能にしてnullを挿入できます。

他のヒント

主な利点は、バグのあるクライアントコードが何かおかしなことをしようとしても、データベースに矛盾が生じないことです。外部キーは「制約」の一種であるため、それを使用する必要があります。

「機能」はありません。利益、彼らは何も最適化しません。インデックスを自分で作成する必要があります。また、はい、外部キーである列にNULL値を含めることができます。

FK制約により、データの一貫性が保たれます。それでおしまい。これが主な利点です。 FK制約により、パフォーマンスが向上することはありません。

しかし、意図的なdb構造で非正規化していない限り、FK制約を使用することをお勧めします。主な理由-一貫性。

ネット上で少なくとも1つの例を読んだところ、データが既に特定の基準を満たしていることがわかっているため、オプティマイザーがテーブル全体で追加のチェックを行う必要がないため、外部キーがパフォーマンスを改善することが示されました FKへ。申し訳ありませんが、リンクはありませんが、ブログはそれを証明するためのクエリプランの詳細な出力を提供しました。

前述のとおり、これらはデータの整合性のためです。すべてのパフォーマンス「損失」破損したデータを修正するのに必要な時間までに完全に消去されます。

ただし、パフォーマンスが間接的に向上する可能性があります。

少なくともSQL Serverの場合、FKの列は両側で同じデータ型でなければなりません。 FKがない場合、たとえば、nvarcharの親とvarcharの子を使用できます。 2つのテーブルを結合すると、パフォーマンスを低下させる可能性のあるデータ型変換が行われます。

例:varcharの長さが異なるため、問題

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top