如何解決邏輯刪除與資料庫唯一約束衝突

前言

不知道大家有沒有遇到這麼一種業務場景，在業務中有個唯一約束A，當該業務進行邏輯刪除後（設定標記為刪除狀態），再往唯一約束列插入相同的值時，此時會報Duplicate entry，但在業務上，該值時必須要插入的。今天我們就來聊聊處理這種業務場景的幾種思路

解決思路

方案一：不採用邏輯刪除，直接物理刪除

方案二:新建歷史表

主表進行物理刪除，同時將刪除的記錄儲存到歷史表中

方案三：取消表的唯一約束，同時引入redis來保證唯一約束

取消表的唯一約束，在專案中引入redis，通過redis來判重，新增時往redis set記錄，刪除時，刪除redis記錄

方案四：變更刪除標記為時間戳

將刪除狀態不以0,1表示，而是以時間戳為值，然後將刪除狀態為與之前的唯一約束A重新組成唯一聯合約束index（A、del_flag），刪除時變更del_flag的時間戳

方案五：保留刪除標記，同時新建一個欄位del_unique_key

保留刪除狀態位，再新增一個欄位del_unique_key,該欄位預設值為0，欄位型別和大小與主鍵id保持一致，同時與原先的唯一約束重新組成聯合唯一約束index(A,del_unique_key),業務進行邏輯刪除，變更del_unique_key的值為該刪除行的主鍵id

方案的取捨

方案一得從業務的角度上考慮了，如果物理刪除，對業務無損，那就無所謂了。方案二等於需要刪除的記錄的表都需要有歷史表，如果僅僅是用來實現記錄刪除記錄，感覺有點大材小用。方案三引入redis，雖然也可以解決問題，但是又額外增加複雜度，同時還得保證redis和資料庫的一致性。方案四和方案五其實實現的思路是一樣，不過如果已經是線上上跑的業務，還是推薦用第五種方案，畢竟新增欄位正常對已有的業務影響相對較小，如果是第四種方案，直接將標誌位修改為時間戳，可能還會涉及改業務。如果是新增業務，第四種和第五種方案比較推薦