触发器的实际使用场景大体说来就是帮你方便的迁移数据, 不过最好不要和业务紧密结合, 因为一个事务的的一部分在java那边, 另另一部分在触发器中是无法很方便的调试/排查/维护的, 唯有一个场景, 就是不想物理删数据的时候
很久以前有个不成文的规定就是, 不要物理删除数据, 所有表都要加上is_delete这个字段来标识某行数据是否被物理删除, 但是当遇到有唯一索引的时候, 这个规则就歇菜了, 因为, 比如name是唯一索引, 当用户添加xiaoming后, 然后删除xiaoming, 这时is_delete = Y,但是再次重新添加xiaoming就不可以了, 因为违反了唯一约束
因此, 这种情况, 就不要更新is_delete了, 而是利用 after delete 类型的触发器将数据迁移到另外的一张表, 比如 user_del 中, 他的字段与user表一致, 只不过多了个记录插入数据时间的字段
大家还有没有其他使用场景呢???????
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
먼저 트리거에 관해서는 많은 대기업들이 사용을 금지하고 있습니다. 첫째로 이식성이 나쁘고 둘째로 성능에 영향을 미친다는 것입니다.
그럼 비물리적 삭제의 경우를 집중적으로 살펴보겠습니다. 고유 키 제약 조건이 있는 테이블과 is_delete와 같은 열을 만나면 정말 고통스럽습니다. 이것이 프로젝트에서 내가 처리하는 방법입니다. 사용자 테이블 user에 다음 열이 있다고 가정합니다.
id(기본 키)
사용자 이름(고유 키)
...
is_delete
삽입 시 고유키가 충돌하는 경우 삭제된 동일한 이름의 사용자가 있는지 확인하세요.
이름이 있고(그리고 ID를 얻은 경우) UPDATE 작업이 수행되면 삭제 취소로 간주됩니다.
그러면 골치 아픈 문제가 발생합니다. 사용자가 삭제해야 하는 경우가 있기 때문에(솔직히 이런 경우는 거의 없음) 사용자 이름을 변경해야 하는 경우도 있습니다. 사용자 이름을 변경하면 기본 키 충돌이 발생하고 기존 사용자가 논리적으로 삭제되었으므로 변경하도록 허용하시겠습니까?
빠른 방법은 고유 키를 "비물리적"으로 만드는 것입니다. 사용자를 생성하기 전에 매번 확인하여 삭제되지 않은 동일한 이름의 사용자를 찾으면 생성도 허용됩니다. 이름 바꾸기를 위해. 그러나 동시성이 높은 경우 SELECT의 이름이 동일하지 않지만 INSERT의 이름이 동일할 수 있으므로 이 작업을 트랜잭션으로 전환해야 할 수도 있습니다.
위 질문
"사용자 이름을 변경하면 기본키 충돌이 발생하고, 기존 사용자는 논리적으로 삭제되었는데 변경을 허용하시겠습니까?"
예 이 방법을 사용하였습니다. 이전에는 소규모 프로젝트에서는 가능했지만 대규모 프로젝트에서는 가능한지 모르겠습니다.
각 테이블은 자동 증가 ID를 사용하며 기본 키 제약 조건은 기본 키 + "is_delete" 제약 조건을 사용합니다.