高い並行性の下で、データベースの外部キーの制約を使用する必要がありますか？

データベースのトレードオフ上の並行性シナリオでの外部キーの制約

高い並行性パフォーマンスを追求するプロジェクトでは、物議を醸す質問がしばしば発生します。データベースで外部のキー制約を使用する必要がありますか？一部の人々は、効率を改善するために、外国の鍵を禁止する必要があると言う人もいます。何が起こっているのか？

実際、いくつかの高い並行シナリオでは、データベースが提供する物理外部キーの制約を使用しないことを選択する必要があります。これは、外部の鍵の概念が完全に放棄されたことを意味するのではなく、データの一貫性を確保するためにデータベース自体が提供する外部キー機能に依存することを避けることを意味します。その理由は、データベースレベルでの外部キーの制約がデータベースの書き込み操作パフォーマンスに影響を与えるため、特に高い並行性環境では、外部のキー検査がパフォーマンスボトルネックになるためです。

それでは、物理的な外部キーが使用されていない場合、データの一貫性をどのように保証できますか？答えは次のとおりです。これは、ビジネスレイヤーを介して実装されています。たとえば、プライマリテーブルデータが削除された場合、Associationテーブルの対応するレコードも削除する必要があります。物理的な外部キーを使用することは、カスケード削除を通じて簡単に実装できますが、物理的な外部キーが無効になっている場合は、それぞれメインテーブルと関連テーブルを削除するために、ビジネスロジックレイヤーにコードを明示的に記述する必要があります。同様に、外部キーの制約の更新操作もビジネス層で処理する必要があります。

このようにして、データベース操作の原子性はデータベースレイヤーからアプリケーションレイヤーに転送されます。アプリケーションレイヤーは、操作の原子性を確保する必要があり、通常、データの整合性を確保するためにトランザクションメカニズムが必要です。

多くの高い並行性シナリオでは、究極の一貫性で十分であることは注目に値します。これは、データの一貫性を同時に完了する必要があり、短い時間ウィンドウを可能にする必要がなく、データが一貫性のない状態にある可能性があることを意味しますが、最終的には一貫性に達します。これは、強い一貫性とは異なります（データはいつでも一貫している必要があります）。究極の一貫性は、高い並行性環境によりよく適応し、システムスループットを改善できます。したがって、データベースの物理的な外国の鍵を放棄し、データの一貫性を担当することは、多くの高い並行性シナリオで実行可能なソリューションです。

以上が高い並行性の下で、データベースの外部キーの制約を使用する必要がありますか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。