外部キーを定義する利点は何ですか
関係を処理するMVCフレームワークで作業するときに外部キーを定義する利点は何ですか？
関係のあるモデル定義を可能にするフレームワークを備えたリレーショナルデータベースを使用しています。外部キーはモデルを通じて定義されるため、外部キーは冗長であるように見えます。開発中のアプリケーションのデータベースを管理する場合、外部キーを使用しているテーブルの編集/削除は面倒です。
外部キーの使用を完全に削除することで、私が忘れている外部キーを使用する利点はありますか？
制約付きの外部キー（一部のDBエンジンでは）は、低レベル（データベースのレベル）でデータの整合性を提供します。つまり、関係を満たさないレコードを物理的に作成することはできません。これは、より安全な方法です。
データベースレベルで適用されるデータの整合性を提供します。これは、無効なデータを引き起こす可能性のあるアプリケーションロジックのエラーから保護するのに役立ちます。
アプリケーションロジックをバイパスするSQLでデータ操作が直接行われる場合、これらの制約を破る不良データからも保護されます。
追加の副次的な利点は、スキーマ自体から推論された関係を持つデータベースダイアグラムをツールが自動的に生成できることです。理論的には、すべての作図はデータベースが作成される前に行う必要がありますが、データベースが最初の具体化を超えて進化するため、これらの図は最新の状態に保たれないことが多く、既存のデータベースから図を生成する機能は両方に役立ちますプロジェクトに参加する新しい開発者に構造を説明するだけでなく、レビューも行います。
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つのBookが参照している著者を削除しようとすると、データベースが破損するのではなく、エラーが発生します。
開発/テストデータを操作するときに面倒なこともありますが、本番環境での面倒を大幅に軽減してくれます。
それらは、特に孤立したレコードに対する保護手段として、データの整合性を維持する方法として考えてください。
たとえば、多くのPhoneNumberレコードをPersonに関連付けているデータベースがある場合、何らかの理由でPhoneNumberレコードが削除されると、Personレコードはどうなりますか？それらは引き続きデータベースに存在しますが、それらが関連するPersonのIDは関連するPersonテーブルに存在せず、孤立したレコードがあります。
はい、PhoneNumberが削除されるたびにPersonを削除するトリガーを作成できますが、Personを誤って削除してロールバックする必要がある場合、これは煩雑になる可能性があります。
はい、PhoneNumberレコードを手動で削除することを覚えているかもしれませんが、9か月後に記述した他の開発者やメソッドについてはどうですか？
PhoneNumberが既存のPersonに関連付けられていることを保証する外部キーを作成することで、この関係を破壊しないことを保証し、目的のデータ構造に関する「手掛かり」を追加します。
主な利点は、データの整合性とカスケード削除です。それらが定義されていて、それらのフィールドに適切にインデックスが付けられている場合にも、パフォーマンスが向上します。たとえば、連絡先に属していない電話番号を作成したり、連絡先を削除するときに、すべての電話番号を自動的に削除するように設定したりすることはできません。はい、UIまたは中間層でこれらの接続を行うことができますが、UIではなくSQLを使用してサーバーに対して直接誰かが更新を実行すると、依然として孤立した状態になります。 「面倒」な部分は、一括変更を行う前にそれらの接続を検討するように強制するだけです。 FKは私のベーコンを何度も救ってきました。