如果我有一个表结构是：
code, description, isdeleted
code主键在哪里。
用户创建一条记录，然后将其删除。因为我使用的是软删除，所以isdeleted将设置为 true。然后在我的查询中，我将使用 where 子句进行选择and not isdeleted
现在，如果用户去创建一条新记录，他们可能会看到代码“ABC”不存在，因此他们尝试重新创建它。由于 where 子句，select 语句不会找到它。但是会出现主键索引错误。
是否应该允许用户重新使用记录？我认为不会，因为软删除的想法是保留对旧数据的查询记录，以便连接到“已删除”记录仍然有效。如果允许用户重新使用代码，那么他们可以更改描述，这可能会改变历史数据的视图。但是完全阻止他们使用该代码是否太苛刻了？
或者我应该使用完全隐藏的主键，然后可以重复使用“代码”字段？
我知道很多人认为数据应该是自然的，但是如果您要支持软删除而不打算总是重用以前的记录，那么您应该使用与数据完全分开的主键出现这种情况。
拥有一个分离的主键将允许您拥有多个具有相同“代码”值的记录，并且它将允许您“取消删除”（否则，为什么要使用软删除？）一个值而不必担心覆盖其他内容。
就个人而言，我更喜欢数字自动递增的 ID 样式，但 GUID 的支持者很多。
或者我应该使用完全隐藏的主键，然后可以重复使用“代码”字段？
我认为您自己已经很好地回答了这个问题。如果您希望用户能够重新使用已删除的代码，那么您应该有一个用户不可见的单独主键。如果代码的唯一性很重要，那么用户通常不应该输入它们。
我认为这取决于您正在谈论的具体数据。
如果用户试图重新创建代码“ABC”，是上次使用的相同“ABC”现在已经退出，还是完全不同的“ABC”？
如果它实际上指的是同一个现实世界的“事物”，那么简单地“取消删除”它可能没有害处。毕竟 - 这是同一件事，所以从逻辑上讲，它应该在历史查询和新查询中显示为同一件事。如果您的用户决定不再需要它，那么他们可以删除它并且它会消失。如果在将来的某个时候他们再次需要它，他们可以通过再次添加它来有效地取消删除它。
但是，如果新的“ABC”指的是（在现实世界中）与旧的“ABC”不同的东西，那么您可以争辩说“代码”实际上不是主键，在这种情况下，如果您的数据不提供任何其他自然选择，您也可以创建任意键。
这样做的一个很大的缺点是你必须非常小心，当然不要让用户创建两个具有相同“代码”的活动记录。
当您选择记录（不包括软删除）以在用户界面/输出文件中显示它们时，请使用 where not isdeleted。
但是当用户请求插入操作时，执行两个查询。
查找所有记录（忽略 isdeleted 值）。
根据第一个查询结果，如果存在则执行 UPDATE（并反转 isdeleted 标志），如果不存在则执行真正的 INSERT。
业务逻辑的细微差别取决于您。
我已经使用用户表完成了此操作，其中电子邮件是唯一约束。如果有人取消了那里的帐户，他们的信息仍然需要参考完整性，所以我要设置 is_deteled 为 true，并在电子邮件字段中添加“_deleted”。这样，如果用户决定以后再次注册，对用户来说没有问题，唯一性约束也不会被打破。
我认为软删除在某些情况下很好。例如，如果有人从该站点删除了他们的帐户，而您删除了他们的用户，那么他们的所有帖子和答案都会丢失。我认为软删除并将他们的用户显示为“已删除用户”或类似的东西要好得多......哦，我也相信分离的主键