問題描述

觸發(fā)器的實(shí)際使用場景大體說來就是幫你方便的遷移數(shù)據(jù), 不過最好不要和業(yè)務(wù)緊密結(jié)合, 因?yàn)橐粋€(gè)事務(wù)的的一部分在java那邊, 另另一部分在觸發(fā)器中是無法很方便的調(diào)試/排查/維護(hù)的, 唯有一個(gè)場景, 就是不想物理刪數(shù)據(jù)的時(shí)候

很久以前有個(gè)不成文的規(guī)定就是, 不要物理刪除數(shù)據(jù), 所有表都要加上is_delete這個(gè)字段來標(biāo)識(shí)某行數(shù)據(jù)是否被物理刪除, 但是當(dāng)遇到有唯一索引的時(shí)候, 這個(gè)規(guī)則就歇菜了, 因?yàn)? 比如name是唯一索引, 當(dāng)用戶添加xiaoming后, 然后刪除xiaoming, 這時(shí)is_delete = Y,但是再次重新添加xiaoming就不可以了, 因?yàn)檫`反了唯一約束

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

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

問題解答

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

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

id (主鍵)

username (唯一鍵)

...

is_delete

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

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

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

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

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

權(quán)宜之計(jì)是把唯一鍵也做成“非物理”的，每次創(chuàng)建用戶前都去查一下，查到?jīng)]有被刪除的同名用戶，就允許創(chuàng)建，改名也一樣。不過這種操作可能要做成事務(wù)了，因?yàn)樵诓l(fā)高的情況下，完全可能SELECT的時(shí)候還沒重名，但I(xiàn)NSERT就重名了。

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