34

SQL には、カスケード削除という優れた機能が常にあります。事前に計画を立てて、何かを削除するときが来たら、BAM! これらすべての依存レコードについて心配する必要はありません。

しかし、今日では、実際に何かを削除することはほとんどタブーです。削除済みとしてフラグを立て、表示を停止します。残念ながら、依存レコードがある場合にこれを行うための確実な解決策を見つけることができませんでした。私は常にソフトデリートの複雑な Web を手動でコーディングしてきました。

私が完全に見逃したより良い解決策はありますか?

4

5 に答える 5

21

言いたくないのですが、トリガーはこの種のことのために特別に設計されています。

(嫌いな部分は、良いトリガーを書くのが非常に難しく、もちろんデバッグできないためです)

于 2009-02-03T09:08:46.323 に答える
7

外部キー制約はカスケード更新を行うことができます。キーと削除フラグの両方でテーブルをリンクした場合、マスター テーブルの削除フラグが変更されたときに、その変更がディテール テーブルに反映されます。私はそれを試していませんが、うまくいくはずです。

于 2009-02-03T09:12:59.947 に答える
2

通常、論理的な削除の利点は、すべてのテーブルに論理的な削除フラグがあるわけではないため、カスケードする必要があるものの数が少ないことだと思います。行はデータベースで単に使用されていませんが、孤立していません。削除された行によって参照されるだけです。

ただし、すべての場合と同様に、モデルによって異なります。

于 2009-02-03T09:13:29.103 に答える
0

どのバックエンドについて話しているのかわかりませんが、「削除フラグ」の変更をピックアップし、トリガーを使用して変更をカスケードすることができます。

于 2009-02-03T09:09:49.423 に答える