リレーションを処理する MVC フレームワークを使用する場合、外部キーを定義する利点は何ですか?
リレーションを使用したモデル定義を可能にするフレームワークを備えたリレーショナル データベースを使用しています。外部キーはモデルを通じて定義されるため、外部キーは冗長に見えます。開発中のアプリケーションのデータベースを管理する場合、外部キーを使用しているテーブルの編集/削除は面倒です。
それらの使用を完全にやめることによって、私が忘れている外部キーを使用する利点はありますか?
リレーションを処理する MVC フレームワークを使用する場合、外部キーを定義する利点は何ですか?
リレーションを使用したモデル定義を可能にするフレームワークを備えたリレーショナル データベースを使用しています。外部キーはモデルを通じて定義されるため、外部キーは冗長に見えます。開発中のアプリケーションのデータベースを管理する場合、外部キーを使用しているテーブルの編集/削除は面倒です。
それらの使用を完全にやめることによって、私が忘れている外部キーを使用する利点はありますか?
制約のある外部キー (一部の DB エンジン) は、低レベル (データベースのレベル) でデータの整合性を提供します。これは、関係を満たさないレコードを物理的に作成できないことを意味します。それは、より安全になる方法にすぎません。
これにより、データベース レベルで適用されるデータの整合性が得られます。これにより、無効なデータを引き起こす可能性のあるアプリケーション ロジックのエラーを防ぐことができます。
アプリケーション ロジックをバイパスするデータ操作が SQL で直接行われた場合、それらの制約を破る不正なデータからも保護されます。
追加の副次的な利点は、ツールがスキーマ自体から推測された関係を使用してデータベース ダイアグラムを自動的に生成できることです。理論的には、データベースを作成する前にすべてのダイアグラムを作成する必要がありますが、データベースが最初の化身から進化するにつれて、これらのダイアグラムは最新の状態に保たれないことが多く、既存のデータベースからダイアグラムを生成する機能は、両方の目的で役立ちます。プロジェクトに参加する新しい開発者に構造を説明するだけでなく、レビューします。
データベース構造がまだ流動的である間は FK を無効にすることが役立つ場合がありますが、スキーマがより安定している場合は FK を使用することをお勧めします。
外部キーは、一致するレコードが外部テーブルに存在することを保証します。Books
というテーブルに FK 制約がある というテーブルを想像してくださいAuthors
。すべての本にはAuthor
.
これで、次のようなクエリを実行できます。
SELECT B.Title, A.Name FROM Books B
INNER JOIN Authors A ON B.AuthorId = A.AuthorId;
FK 制約がないと、Author
行が欠落すると行全体Book
が削除され、データセットに書籍が欠落することになります。
また、FK 制約を使用すると、少なくとも 1 つの書籍で参照されている著者を削除しようとすると、データベースが破損するのではなく、エラーが発生します。
開発/テスト データを操作するときは面倒かもしれませんが、本番環境では多くの手間が省けました。
それらは、特に孤立したレコードに対する保護手段として、データの整合性を維持する方法と考えてください。
たとえば、多くのPhoneNumber
レコードを に関連付けるデータベースがある場合、何らかの理由でレコードが削除された場合、レコードはPerson
どうなりますか? それらはデータベースに引き続き存在しますが、関連する ID は関連するテーブルに存在しなくなり、孤立したレコードになります。PhoneNumber
Person
Person
Person
はい、PhoneNumber
a が削除されるたびに を削除するトリガーを作成できますがPerson
、誤って aPerson
を削除してロールバックする必要がある場合、これは面倒になる可能性があります。
PhoneNumber
はい、手動でレコードを削除することを覚えているかもしれませんが、 9 か月後に作成した他の開発者やメソッドについてはどうでしょうか?
いずれかPhoneNumber
が既存のPerson
.
主な利点は、データの整合性とカスケード削除です。それらが定義され、それらのフィールドが適切にインデックス付けされている場合、パフォーマンスの向上も得られます。たとえば、連絡先に属していない電話番号を作成することはできません。または、連絡先を削除するときに、すべての電話番号を自動的に削除するように設定できます。はい、UI または中間層でこれらの接続を作成できますが、誰かが UI ではなく SQL を使用してサーバーに対して直接更新を実行すると、孤立してしまいます。「面倒」な部分は、一括変更を行う前に、これらの接続を考慮することを強制しているだけです。FK は私のベーコンを何度も救ってくれました。