MySQLで大規模なデータベースを構築し、SQLYogを使用してテーブル間のすべての関係を作成しました。それはすべてうまくいっていますが、私が構築しているPHPサイトでは、データベースから行を削除する際に問題が発生することがよくあり、参照整合性制約に遭遇することがよくあります。そこで、最初にリンクテーブルからデータを削除するか、フィールドをNULLに設定してみます。私は通常、これをある程度の試行錯誤で機能させることができますが、これを実行する方法や適切なプロセスがないようです。'削除セットNULLまたはカスケード削除設定'を使用する必要がありますか？どちらを使用すればよいかわからないので、他のテーブルの重要なデータが削除されるのではないかと心配しています。
人々はデータベースに関係の制約を設定することさえわざわざしますか？つまり、削除を実行してから、PHPコードでリンクされている他のテーブルを更新するために、いくつかの追加行を書き込む方がはるかに簡単に思えます。
どんな助けでも大歓迎です。
データベースは、外部のデータを信頼してはならないという点で、独自の領地として扱われるべきです。データベースへの直接接続が必要で、元のアプリケーションによって設定されたルールが破られたシステムをよく見てきました。データベースは多くの場合、複数のアプリケーションで使用されるようになるため、独自のデータ整合性を実装することが不可欠です。他の開発者がアプリケーションまたは中間層を完全にバイパスすると想定します。さらに、データベースは、データベースにサービスを提供するために最初に作成されたアプリケーションよりもはるかに長くサービスを維持する傾向があります。
したがって、そうです、外部キー制約、null 可能性制約の適切な使用などをデータベース設計に組み込むことが重要です。発生しているこれらの参照整合性制約は、孤立した行からデータを保護するために存在します。さらに、テーブルが相互にどのように関連しているかについてのドキュメントを提供します。
親が削除されたときに論理的に削除する必要がある子エンティティがある場合は、カスケード削除を検討できます。親を削除するすべてのコードがすでに子を削除するようにコード化されていない限り、削除をカスケードしないように注意する傾向があります。その場合は、削除をカスケードすることもできます。カスケード更新は明らかに安全であり、パフォーマンスが心配な場合や設計上の制限により実装できない場合を除いて、通常、カスケード更新を実装しない理由はありません。
保存するデータのタイプによって異なりますが、データに参照整合性が本当に必要ですか? ほとんどの「情報システム」では、これは必須です。
2番目の段落を参照してください：
PHPコードでリンクされている他のテーブルを更新するために、削除を行ってから追加の行を書く方がはるかに簡単に思えるということです。
はい、おそらく小規模なシステムのみを作成している場合の方が簡単ですが、アプリケーションが成功し、より多くの顧客、より多くの機能を実装する必要があり、より多くのプログラマーが必要になると想像してみてください。そうすれば、必然的に更新/削除を忘れるでしょう. /関連するデータをデータベースに挿入します。その瞬間、Codd が言ったのは冗談ではなかったことがわかります。
整合性制約は、アプリケーション プログラムとは別に指定し、カタログに格納する必要があります。既存のアプリケーションに不必要な影響を与えることなく、必要に応じてそのような制約を変更できる必要があります。
ここでcoddのルールを読んでください
参照整合性を制御する必要がある場合 (ほとんどの場合、制御する必要があると思います) は、常に DBMS に作業を任せたほうがよいでしょう。
同じデータを使用する他のアプリケーションが (現在または将来) 存在する可能性があるためだけでなく、効率的な理由からも、同じデータを使用している可能性があります。
優れた DBMS は常に制約をチェックします (たとえば、外部キーの挿入が有効な a 値 (つまり、参照されるテーブルに存在する値) を保持しているかどうかのチェック) は、コードよりも高速です。この種のチェックはリレーショナル データベースの中核であるため、DBMS はこれらのデータベースに対して非常に最適化されています。