一、背景

今天運營反饋了一個策略新建失敗的問題。失敗原因是新增策略名稱與存量數(shù)據(jù)的策略名稱重復，且策略名稱為唯一索引，insert時觸發(fā)數(shù)據(jù)庫唯一鍵約束導致插入失敗。但占用該名稱的策略已經(jīng)被刪除了，業(yè)務上處于不可見狀態(tài)。

這是由軟刪除設(shè)計與唯一性約束引發(fā)的沖突問題，怎么解呢？

二、示例環(huán)境

表名 : t_strategy

業(yè)務唯一鍵 : name
數(shù)據(jù)庫唯一鍵 : name

三、方案選型

3.1 物理刪除

物理刪除沒有這個煩惱，但得從業(yè)務和所在環(huán)境的角度上考慮是否可行。

所在的業(yè)務和團隊是否允許物理刪除？
對于存量重復記錄如何訂正？

跑題了～

3.2 is_deleted 存儲刪除時間

is_deleted 為 0 時，代表記錄生效中；is_deleted 非 0 時，代表記錄已刪除，且字內(nèi)容為刪除時間。

數(shù)據(jù)庫唯一鍵調(diào)整為 : name + is_deleted

示例環(huán)境的 is_deleted 類型為 TINYINT ，該方案涉及表結(jié)構(gòu)變更。
如上，所在的業(yè)務和環(huán)境是否允許此操作？

3.3 is_deleted 存儲業(yè)務唯一鍵下的自增值

is_deleted 為 0 時，代表記錄生效中；is_deleted 非 0 時，代表記錄已刪除，且字內(nèi)容為“自增值”。

數(shù)據(jù)庫唯一鍵調(diào)整為 : name + is_deleted

TINYINT 的值范圍有限，能否滿足業(yè)務訴求？
“自增”邏輯需要自行實現(xiàn)，且依賴一次查詢。

3.4 補充業(yè)務唯一鍵

3.4.1 新增 deleted_time 字段

deleted_time 即刪除時間。

deleted_time 默認值為 NULL 或者 0 ；記錄被刪除時，將 deleted_time 賦值為 now()。

數(shù)據(jù)庫唯一鍵調(diào)整為 : name + deleted_time

邏輯自洽，通俗易懂
實現(xiàn)上比較簡單，在軟刪時將 deleted_time 置為 now() 即可。

3.4.2 新增 deleted_primary_key 字段

deleted_primary_key 即刪除的主鍵。

deleted_primary_key 默認值為 NULL 或者 0 ；記錄被刪除時，將 deleted_primary_key 賦值為行主鍵。

數(shù)據(jù)庫唯一鍵調(diào)整為 : name + deleted_primary_key

實現(xiàn)上也比較簡單，在軟刪時將 deleted_primary_key 置為 id 即可。

3.5 刪除數(shù)據(jù)分表存儲

刪除數(shù)據(jù)由刪除表統(tǒng)一保存，原表不再保存刪除數(shù)據(jù)，僅原表保持uk校驗。

is_deleted 默認值為 0 ；記錄被刪除時，將該數(shù)據(jù)插入到刪除表。

如果所在的業(yè)務和環(huán)境允許物理刪除，那么壓根不存在軟刪問題；如果不允許，記錄刪除時，將 is_deleted 賦值為 1。
當業(yè)務主鍵沖突時有兩種情況，業(yè)務失敗或者數(shù)據(jù)覆蓋。
技術(shù)實現(xiàn)相比上述幾個方案更為復雜，不建議使用。

常規(guī)方案推薦

3.2 is_deleted 存儲刪除時間 > 3.4.1 新增 deleted_time 字段 > 3.4.2 新增 deleted_primary_key 字段

is_deleted 不需要或者所在業(yè)務和環(huán)境允許表結(jié)構(gòu)變更，優(yōu)先選取方案 : 3.2 is_deleted 存儲刪除時間，否則往下走。
如果 deleted_time 能滿足未來并發(fā)訴求，則用方案 3.4.1 新增 deleted_time 字段；否者采用方案 4.2 新增 deleted_primary_key 字段。
從業(yè)務語義上看，刪除時間本身是帶業(yè)務含義的，只是當前業(yè)務沒有用到。而被刪除的主鍵，僅僅只是為了解決技術(shù)上的問題，沒有帶來增量的業(yè)務價值。