关于数据库设计：重复使用软删除的记录

如果我有一个表结构是：

其中code是主键。

用户创建一条记录，然后将其删除。由于我正在使用软删除，因此isdeleted将设置为true。然后在查询中，我将使用where子句and not isdeleted进行选择

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

是否应该允许用户重复使用记录？我认为不会，因为软删除的想法是保留记录以查询较旧的数据，以便联接到"已删除"的记录仍然有效。如果允许用户重复使用代码，则他们可以更改描述，这可能会更改历史数据的视图。但是，要阻止他们完全使用该代码是否太苛刻？

还是应该使用完全隐藏的主键，然后可以重新使用"代码"字段？

---

我知道很多人都认为数据应该是自然的，但是如果要支持软删除，而又不想在重用时重复使用以前的记录，则应该使用与数据完全独立的主键。这种情况出现了。

离婚的主键将允许您拥有具有相同"代码"值的多个记录，并且将使您可以"取消删除"一个值(否则，为什么要进行软删除？)而不必担心会覆盖其他内容。

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

---

Or should I be using a completely
hidden primary key and then the 'code'
field can be re-used?

我认为您已经很好地回答了这个问题。如果您希望用户能够重复使用已删除的代码，那么您应该拥有一个单独的主键，该键对用户不可见。如果唯一的代码很重要，那么用户通常无论如何都不应该输入它们。

---

我认为这取决于您正在谈论的特定数据。

如果用户试图重新创建代码" ABC"，是上次使用的SAME" ABC"现在已经退出淘汰，还是完全不同的" ABC"？

如果它实际上指的是真实世界中的"事物"，那么简单地"删除"它可能不会有任何危害。毕竟-这是同一件事，因此从逻辑上讲，它应该在历史查询和新查询中显示为同一件事。如果您的用户决定不再需要它，则可以将其删除，然后它就会消失。如果将来某个时候他们再次需要它，则可以通过再次添加它来有效地取消删除它。

但是，如果新的" ABC"(在现实世界中)所指的东西与旧的" ABC"不同，那么您可能会认为"代码"实际上不是主键，在这种情况下，如果您的数据没有提供任何其他自然选择，您也可以创建一个任意密钥。

一个很大的缺点是，您必须非常小心，不要让用户使用相同的"代码"创建两个活动记录。

---

我已经通过用户表完成了此操作，其中电子邮件是唯一的约束。如果有人取消那里的帐户，则仍然需要他们的信息来确保参照完整性，因此将"我"设置为is_deteled为true，然后在电子邮件字段中添加" _deleted"。以这种方式，如果用户决定将来再次注册，则对于用户来说没有问题，并且唯一约束没有被破坏。

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

---

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

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

查找所有记录(忽略isdeleted的值)。

根据第一个查询结果，如果存在则执行UPDATE(并带有反向isdeleted标志)，或者如果不存在则执行真正的INSERT。

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

---