入門
実際には、このトピックでは、多くの人々が自分の仕事に外部キーを使用していない、一般的です。含むアリJAVAの仕様では、この1次があります。
[]、アプリケーション層で対処しなければならないすべての外部キーの概念をカスケードと外部キーを強制的に使用してはなりません。
しかし、その後、それらを求める理由は、それらのほとんどは、このように答えました：
それは非常に苦痛の時間の開発につながるだろう、たびに、DELETE、またはUPDATEが外部キー制約を考慮しなければなりません、テストデータは、非常に不便です。
率直に言って、言うは正しいです。しかし、それは包括的に十分ではありませんので、細部に紙を開きます。
テキスト
まず、我々はそれが外部キー制約は、制約、この制約の存在であることは明らかにし、テーブルのデータ間の関係は、「いつもいっぱいです。」ことを保証します このように、外部キー制約はなく、完全にメリットなし。このような外部キーとして、あなたがすることができます：
-
データの整合性と一貫性を確認してください。
-
簡単カスケード操作;
-
データベースに委託データの整合性を分析が完了すると、コードサイズが小さくなります。
しかし、魚やクマの足の両方を持つことはできません。外部キーは、データの整合性を確保することであるが、システムは欠陥の多くをもたらすでしょう。そのためこれらの欠点のため、唯一、次のように、外部キーを使用することをお勧めして私たちを導きます：
パフォーマンスの問題
user_tbというテーブルを想定。そして、この表には、二つのテーブルを指し、2つの外部キーフィールドを持っています。だから、データ挿入user_tbテーブルにするたびに、対応するデータがあるかどうか、クエリに対応する2つの外部キーテーブルに必要です。プログラムの制御を引き渡した場合は、そのようなクエリ処理は我々の手で制御することができる、あなたはいくつかの不必要なクエリ処理を省略することができます。データベースによって制御される場合しかし、あなたは、これら二つの裁判官のテーブルに移動する必要があります。
同時実行の問題
外部キーを使用する場合には、データのニーズの各変更は、別のチェック表データ、追加のロックを取得する必要があるに移動します。高同時大量のトランザクションのシナリオの場合、デッドロックが発生する可能性が高く、外部キーを使用して。
スケーラビリティの問題
これは主に二つに分かれています。
-
そのようなあなたのように便利なプラットフォームの移行を作る
Mysqlに移動するOracleこの種のもののトリガ、外部キーのように、あなたが達成するためのフレームワーク自体の機能を利用するのではなく、データベース自体の特性に依存することができ、より容易な移行を行います。 -
便利なサブライブラリーサブテーブルは、水平分割およびサブライブラリーの場合には、外部キーは力ではありません。データ間の関係を維持し、アプリケーションに入れて、サブライブラリーサブテーブルの将来のために多くの問題を解消します。
技術的な問題
外部キーは、実際には、実行されるアプリケーションの決意ロジックは、データベースに転送されます。次に、データベースのパフォーマンス・オーバーヘッドが大きくなることを、この手段は、さらに高い必要DBA。彼らはデータベースの消費量を削減、外部キーを行うことを選択しますので、多くの中小企業のための資金調達の問題、とは、プロのDBAを雇っていませんでした。
アプリケーションでの制約ロジックは、アプリケーションサーバのパフォーマンスが見つからない場合は逆に、機械は水平拡張を行うために、追加することができます。あなたは、データベース・サーバー上にある場合、データベース・サーバは、パフォーマンスのボトルネックになる可能性が、水平方向の拡大がより困難行います。
オリジナル住所：https://blog.csdn.net/bntx2jsqfehy7/article/details/85813899