プログラマーとして、オブジェクトへの参照を追加することはかなり安全ですが、外部キー関係(私は思う)を追加することはかなり危険です。FK関係を追加することにより、この外部テーブルから行を削除するすべてのクエリを更新して、実際に行を削除する前に、その行に関連付けられている外部キーを適切に削除する必要があります。この外部テーブルから行を削除するすべてのクエリをどのように検索しますか?これらのクエリは、コードやストアドプロシージャに埋もれている可能性があります。これは、メンテナンスの悪夢の実際の例ですか?この問題の解決策はありますか?
4 に答える
あなたの発言は単に真実ではありません。外部キー関係を確立するときに、カスケードプロパティをに設定できますcascade delete
。これが完了すると、親が削除されたときに子レコードが削除され、孤立したレコードがないことが保証されます。
適切なORMソリューションを使用し、FKとPKを正しく構成し、カスケード削除を有効にすれば、問題は発生しないはずです。
私はそうは言いません(他の人が言ったことを確認するために)-それは通常、カスケード削除で処理されます。あなたがそれをそのように望むことを提供する-または背後にあるものをきれい にする注意深い手順で。
より大きなシステムでは、「手順」が多くなり、「自動化」が少なくなります(つまり、カスケード削除)。大規模なセットアップの場合-DBAは通常、データベースのメンテナンスフェーズでこれに対処することを好みます。多くの場合、ミドルウェアアプリケーションコードを介してレコードを削除することは許可されていませんが、単に「削除済み」または非アクティブとしてマークされ、組織内で実施されているデータベースルーチンおよび手順(アーカイブなど)に従って後で処理されます。 。
そして、あなたが非常に大きなコードベースを持っていない限り、それは大きな問題ではありません。また、通常、ほとんどのDbコードは、簡単にトラバースできるDALレイヤーを通過します。または、すべての関係と「依存関係」についてシステムテーブルにクエリを実行することもでき、そのようなコードのメンテナンスのために多くのルーチンが作成されました(「フェンス」の両側)。それが「問題」ではないということではなく、通常のDb作業と大差ないだけであり、それよりも悪いことがあります。
So, I wouldn't lose my sleep over that
。参照整合性制約(パフォーマンス、メンテナンス)の「多すぎる」の使用に関しては他にも問題がありますが、これはDBA(および一般的なDbプロフェッショナル)の間で非常に物議を醸す問題であることが多いため、ここでは取り上げません。 :)
最初から外部キーなしでリレーショナルデータベースを設計するべきではありません。これは、時間の経過とともにデータの整合性が低下することを保証します。
他の人が示唆しているように、コードを追加してカスケード削除を使用することもできますが、それも間違った答えであることがよくあります。子レコードがあるために、本当に削除を停止したい場合があります。たとえば、顧客と注文があるとします。注文のある顧客を削除すると、注文の財務記録が失われ、災害になります。代わりに、この顧客の注文が存在するというエラーをアプリケーションで取得する必要があります。さらにカスケード削除すると、突然何百万もの子レコードが削除され、巨大なトランザクションが発生している間にデータベースがロックされる可能性があります。これは危険な行為であり、本番データベースで使用されることはめったにありません。
FKを追加し(関係がある場合は必要です)、そのテーブルから削除するコードを検索して適切に調整します。ソフト削除が適切なオプションではないかどうかを検討してください。これは、レコードを削除済みまたは非アクティブとしてマークする場所であるため、データ入力オプションとして表示されなくなりますが、既存のレコードは引き続き表示されます。繰り返しますが、これを正しく実装するには、データベースコードをかなり厳しく調整する必要があります。最初からひどく設計されたデータベースを持つための簡単な修正はありません。
ソフト削除は、子レコードが多数あり、実際にそれらを削除したい場合にも適しています。このようにして、レコードにマークを付けて、アプリケーションに表示されないようにし、ピーク時間外に実行されるジョブを使用してレコードをバッチ削除できます。
新しいテーブルを追加してFKを追加する場合は、テーブルに対してコードを記述する前にテーブルを作成するため、処理が確実に簡単になります。