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