3

ソフト削除が使用される単純なスキーマがあります（これが設計方法であり、変更できません）。スキーマに参加するテーブルは2つありますCompany (id, is_deleted)。もちろん、テーブルへEmployee (id, company_id, is_deleted)のcompany_idFKです。Companyルールは次のとおりです。

  • aCompanyがを持っている場合、その会社を参照しているis_deleted = trueすべてのがを持っている必要があります。Employeeis_deleted = true
  • しかし、親がEmployee持っていても、持っている可能性があります。is_deleted = trueCompanyis_deleted = false

私の2つの問題は、a）これらの制約をどのように適用するかです。b）aがソフト削除されis_deleted = trueたときにカスケードされることを最も簡単に確認する方法。Company

タグpostgresqlとsqlserverを追加したのは、これらが私が最も興味を持っているデータベースだからです。他のrdbms：esに他のソリューションがある場合は、それらについても聞きたいです。

4

1 に答える 1

4

厳密に言えば、そのような値をカスケードする唯一の方法は、ONUPDATECASCADEを使用することです。これを行うには、列「is_deleted」が一意性制約の一部である必要があります。

それだけでも難しいことではありません。company.idが主キーの場合、列のペア{id、is_deleted}も一意になります。その列のペアに対する一意の制約により、外部キー参照を介して更新をカスケードできます。

ただし、参照する値が参照される値と異なるようにする必要があるため、これはあなたのケースでは機能しません。

したがって、あなたの場合、3つの選択肢があると思います。

  • トリガー
  • ストアドプロシージャ
  • アプリケーションコード

これらすべての場合において、アクセス許可（おそらく削除アクセス許可を取り消す）とコードを回避できる場合に注意を払う必要があります。たとえば、dbmsコマンドラインインターフェイスとGUIインターフェイスを使用して、アプリケーションコード、および権限に応じてストアドプロシージャの制約を回避できます。

于 2012-11-09T12:34:24.327 に答える