mysql - 触发器的实际使用场景, 可能也就是这个了, 一起讨论还有没有别的

Question

触发器的实际使用场景大体说来就是帮你方便的迁移数据, 不过最好不要和业务紧密结合, 因为一个事务的的一部分在java那边, 另另一部分在触发器中是无法很方便的调试/排查/维护的, 唯有一个场景, 就是不想物理删数据的时候

很久以前有个不成文的规定就是, 不要物理删除数据, 所有表都要加上is_delete这个字段来标识某行数据是否被物理删除, 但是当遇到有唯一索引的时候, 这个规则就歇菜了, 因为, 比如name是唯一索引, 当用户添加xiaoming后, 然后删除xiaoming, 这时is_delete = Y,但是再次重新添加xiaoming就不可以了, 因为违反了唯一约束

因此, 这种情况, 就不要更新is_delete了, 而是利用 after delete 类型的触发器将数据迁移到另外的一张表, 比如 user_del 中, 他的字段与user表一致, 只不过多了个记录插入数据时间的字段

大家还有没有其他使用场景呢???????

Answer 1

まず、トリガーに関しては、多くの大企業がその使用を禁止しています。第一に、トリガーは移植性が低く、第二に、パフォーマンスに影響を与えるからです。

次に、非物理的な削除の状況に焦点を当てましょう。一意キー制約のあるテーブルと is_delete のような列に遭遇すると、本当に苦痛です。これがプロジェクトでの処理方法です。ユーザー テーブル user に次の列があると仮定します。

• id (主キー)

• ユーザー名 (一意のキー)

• ...

• is_delete

挿入時に一意のキーが競合する場合は、同じ名前の削除されたユーザーが存在するかどうかを確認します:

リーリー

同じ名前を持っている (ID を取得している) 場合は、UPDATE 操作を実行すると、削除取り消しとみなされます:

リーリー

そこで、ユーザーは削除する必要があるため (正直、この種の要求はまれです)、ユーザー名を変更する必要もあります。ユーザー名を変更すると主キーの競合が発生し、既存のユーザーは論理的に削除されています。そのため、ユーザーに変更を許可しますか?

ユーザーを作成する前に毎回確認して、削除されていない同じ名前のユーザーがあれば、作成を許可します。改名のため。ただし、同時実行性が高い場合は、SELECT の名前が同じでなくても、INSERT の名前が同じである可能性が十分にあるため、この操作をトランザクションに変換する必要がある場合があります。

Answer 2

上の階からの質問
「ユーザー名を変更すると主キーの競合が発生し、既存のユーザーは論理的に削除されています。そのため、変更を許可しますか?
はい、この方法は で使用されています。」以前は小規模なプロジェクトを行っていましたが、大規模なプロジェクトでも実現可能かどうかはわかりません。
各テーブルは自動インクリメント ID を使用し、主キー制約は主キー + "is_delete" 制約を使用します。