如果我有一個表結構是：重新使用軟刪除的記錄
code, description, isdeleted
其中code是主鍵。
用戶創建一個記錄，然後再刪除它。因爲我正在使用軟刪除，所以isdeleted將被設置爲true。然後在我的查詢中，我將使用where子句進行選擇and not isdeleted
現在，如果用戶創建新記錄，他們可能會看到代碼'ABC'不存在，因此他們試圖重新創建它。由於where子句，select語句不會找到它。但是會有主鍵索引錯誤。
應該允許用戶重新使用該記錄嗎？我認爲不會，因爲軟刪除的想法是保留對舊數據的查詢記錄，以便連接到「已刪除」的記錄仍然有效。如果允許用戶重新使用代碼，則他們可以更改可能會改變歷史數據視圖的描述。但是阻止他們使用該代碼太苛刻了嗎？
或者我應該使用一個完全隱藏的主鍵，然後'code'字段可以重新使用？
我知道很多人都認爲數據應該是自然的，但是如果您打算支持軟刪除而不是始終重複使用，則應該使用與數據完全分離的主鍵這種情況出現時的先前記錄。
離婚主鍵可以讓你有多個記錄具有相同的'code'值，它將允許你「取消刪除」（否則，爲什麼還要用軟刪除？）一個值，而不用擔心覆蓋別的東西。
就個人而言，我更喜歡ID的數字自動遞增樣式，但也有很多GUID的支持者。
或者我應該使用一個完全 隱藏的主鍵，然後在「代碼」 字段可以重複使用？
我想你已經很好地回答了這個問題。如果您希望用戶能夠重新使用已刪除的代碼，那麼您應該有一個單獨的主鍵對用戶不可訪問。如果代碼是唯一的，那麼用戶通常不應該輸入它們。
我認爲這取決於你正在談論的具體數據。
如果用戶正在嘗試重新創建代碼「ABC」，那麼它是上一次使用的相同的「ABC」，現在是退休還是完全不同的「ABC」？
如果它實際上是指相同的現實世界的「事物」，那麼簡單地'取消'它可能沒有害處。畢竟 - 這是同樣的事情，所以從邏輯上講，它應該在歷史和新的查詢中顯示爲相同的東西。如果你的用戶決定他們不再需要它，那麼他們可以刪除它，它會消失。如果在將來的某個時刻他們再次需要它，他們可以通過再次添加它來有效地將其刪除。
但是，如果新的'ABC'是指與舊的'ABC'不同的東西（在現實世界中），那麼你可以爭辯說'代碼'不是實際上是主鍵在這種情況下，如果你的數據沒有提供任何其他的自然選擇，你可以創建一個任意的密鑰。
這方面的一個大缺點是，你必須非常小心，不要讓用戶創建兩個活動記錄使用相同的「代碼」，當然。
選擇記錄時（不包括軟刪除）用戶界面/輸出文件顯示它們，使用其中請將isDeleted沒有。
但是，當用戶請求插入操作，執行兩個查詢。
查找所有記錄（請將isDeleted忽略值）。
基於第一查詢結果，如果存在執行更新（和反向標誌請將isDeleted），或者如果它不存在，執行真正INSERT。
業務邏輯的細微差別是由您決定。
我已經與用戶表，其中電子郵件是唯一約束做到了這一點。如果有人取消了賬戶，他們的信息仍然需要參照完整性，所以我設置了is_deteled爲true，並在電子郵件字段中添加'_deleted'。這樣，如果用戶決定在將來再次註冊，則對用戶來說沒有問題，並且獨特的約束不會被破壞。
我認爲軟刪除在某些情況下取得良好。例如，如果有人從本網站刪除了他們的帳戶，並且您刪除了他們的用戶，那麼他們的所有帖子和答案都將丟失。我認爲軟刪除並將他們的用戶顯示爲「已刪除的用戶」或類似的東西會好得多......哦，我也相信離婚主鍵