Question

如果我有一个表结构：

code, description, isdeleted

其中code是主键。

用户创建一条记录，然后再删除它。因为我使用软删除，isdeleted将设置为true。然后在我的查询中，我将使用where子句and not isdeleted

进行选择

现在，如果用户创建新记录，他们可能会看到代码“ABC”不存在，因此他们尝试重新创建它。由于where子句，select语句将找不到它。但是会出现主键索引错误。

是否允许用户重新使用该记录？我想不会因为软删除的想法是保留旧数据查询的记录，以便加入“已删除”记录仍然有用。如果允许用户重新使用代码，则他们可以更改可能更改历史数据视图的描述。但要阻止他们使用该代码是否过于苛刻？

或者我应该使用完全隐藏的主键，然后可以重复使用“代码”字段？

Answer 1

我知道很多人都认为数据应该是自然的，但如果您要支持软删除而不打算一直重复使用，那么您应该使用与您的数据完全分开的主键。出现这种情况时的先前记录。

拥有离婚的主键将允许您拥有具有相同“代码”值的多个记录，并且它将允许您“取消删除”（否则，为什么要使用软删除？）一个值而不必担心覆盖某些内容其他

就个人而言，我更喜欢数字自动递增的ID样式，但有很多GUID的支持者。

Answer 2

或者我应该完全使用隐藏主键然后'代码' 字段可以重复使用吗？

我想你自己已经很好地回答了这个问题。如果您希望用户能够重新使用已删除的代码，那么您应该拥有一个不可见的用户主键。如果代码必须是唯一的，那么用户通常不应该输入它们。

Answer 3

我认为这取决于您所谈论的具体数据。

如果用户正在尝试重新创建代码'ABC'，那么上次使用的SAME'ABC'现在已经退役了，还是完全不同的'ABC'？

如果它实际上指的是同一个真实世界的“东西”，那么简单地“取消删除”它就没有任何害处。毕竟 - 它是一样的，所以从逻辑上讲它应该在历史和新的查询中显示为相同的东西。如果您的用户决定他们不再需要它，那么他们可以删除它并且它会消失。如果将来他们再次需要它，他们可以通过再次添加它来有效地取消删除它。

然而，如果新的'ABC'指的是（在现实世界中）与旧的'ABC'不同的东西，那么你可以说'代码'实际上不是主键，在这种情况下，如果您的数据没有提供任何其他自然选择，您也可以创建一个任意键。

这方面的一个重大缺点是，你必须非常小心，不要让用户创建两个具有相同“代码”的活动记录。

Answer 4

当您选择记录（不包括软删除）以在用户界面/输出文件中显示它们时，请使用未删除的位置。

但是当用户请求插入操作时，请执行两次查询。

业务逻辑的细微差别取决于您。

Answer 5

我使用用户表完成此操作，其中电子邮件是唯一约束。如果某人取消了该帐户，则仍需要他们的参考完整性信息，因此将我设置为is_deteled为true，并将“_deleted”添加到电子邮件字段。这样，如果用户决定将来再次注册，则用户没有问题，并且不会破坏唯一约束。

我认为软删除在某些情况下是好的。例如，如果有人从此网站删除了他们的帐户并删除了他们的用户，那么他们的所有帖子和答案都将丢失。我认为软删除并将其用户显示为“已删除的用户”或类似的东西要好得多......哦，我也相信离婚的主键