問題描述

觸發器的實際使用場景大體說來就是幫你方便的遷移數據, 不過最好不要和業務緊密結合, 因為一個事務的的一部分在java那邊, 另另一部分在觸發器中是無法很方便的調試/排查/維護的, 唯有一個場景, 就是不想物理刪數據的時候

很久以前有個不成文的規定就是, 不要物理刪除數據, 所有表都要加上is_delete這個字段來標識某行數據是否被物理刪除, 但是當遇到有唯一索引的時候, 這個規則就歇菜了, 因為, 比如name是唯一索引, 當用戶添加xiaoming后, 然后刪除xiaoming, 這時is_delete = Y,但是再次重新添加xiaoming就不可以了, 因為違反了唯一約束

因此, 這種情況, 就不要更新is_delete了, 而是利用 after delete 類型的觸發器將數據遷移到另外的一張表, 比如 user_del 中, 他的字段與user表一致, 只不過多了個記錄插入數據時間的字段

大家還有沒有其他使用場景呢???????

問題解答

首先關于觸發器，很多大公司是禁止使用的，一是可移植性差，二是影響性能，這也是我強烈主張的。

然后著重討論下非物理刪除的情況吧。碰到有唯一鍵約束并且有is_delete這種列的表，確實特別蛋疼的。我在項目中是這么處理的，假設用戶表user有這么幾列：

id (主鍵)

username (唯一鍵)

...

is_delete

插入時，如果唯一鍵沖突，那就查一下有沒有被刪掉的同名用戶：

SELECT id FROM user WHERE username = ? AND is_delete = 1

有同名的話(并且得到了id)做一個UPDATE操作，就當是恢復刪除了：

UPDATE user SET ..., is_delete = 0 WHERE id = ?

然后蛋疼的問題就來了，既然用戶有刪除的需求(說實話這種需求是不多見的)，也就有改用戶名的需求。改用戶名遇到主鍵沖突，并且已存在的用戶是已被邏輯刪除的，那么你到底是讓他改還是不讓他改呢？

權宜之計是把唯一鍵也做成“非物理”的，每次創建用戶前都去查一下，查到沒有被刪除的同名用戶，就允許創建，改名也一樣。不過這種操作可能要做成事務了，因為在并發高的情況下，完全可能SELECT的時候還沒重名，但INSERT就重名了。

樓上的問題'改用戶名遇到主鍵沖突，并且已存在的用戶是已被邏輯刪除的，那么你到底是讓他改還是不讓他改呢？'有個辦法 以前在小項目使用過，不知道大的項目可不可行。每個表都使用自增ID，主鍵的約束使用 主鍵+'is_delete' 的約束。