如果我有一个表结构是：重新使用软删除的记录
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'。这样，如果用户决定在将来再次注册，则对用户来说没有问题，并且独特的约束不会被破坏。
我认为软删除在某些情况下取得良好。例如，如果有人从本网站删除了他们的帐户，并且您删除了他们的用户，那么他们的所有帖子和答案都将丢失。我认为软删除并将他们的用户显示为“已删除的用户”或类似的东西会好得多......哦，我也相信离婚主键