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