一提到軟刪除， 大家一定會說到， isDeleted這個字段， 或者叫status，關於這個可以看一下其他博友的文章
但是這種設計真的好嗎， 其實針對不同的場景， 我們可以採用不同的設計方案來減少設計的複雜度。
考慮下面的場景： 你是後臺API提供方， 調用者每天會定時向你發送一批全量數據， 這些數據每天都會有一定的差別， 比如新增了xx新的記錄， 減少了xx條老的記錄， 還有xx條記錄不變， 你需要支持每天的實時查詢， 保證數據的實效性， 過期數據不應該被顯示。
如果使用isDelete這種方案， 試想一下， API後臺的邏輯實現會比較複雜。難道你要求調用者向你提供那些數據應該被軟刪除麼？ 只能你自己在代碼中做一個判斷， 比如今天有哪些數據的 last_update_time仍舊沒變的， 說到last_update_time， 那這個字段就是本文的亮點。 你只需保證有這一列， 並且使用數據庫的控制， 比如mysql的 on update currenttimestamp， 那麼你就無需做多餘的判斷， 只需要無腦的接受數據， 更新or插入就好了， 向外提供查詢接口的時候只需要sql中where條件加一個last_update_time=今天就OK了。
這種方案的侷限性也有， 就是在一些訂單或者其他有複雜邏輯的地方不適用。 但起碼證明了說每一個表設計都需要有last_update_time這個字段。