场景：“发票”引用了“用户”类。用户对象通过用户本人或管理员删除，但发票对象仍需要接收者（用户）。
用户对象可以被标记为已删除，而不是物理删除它。但我认为使用标记为已删除的对象是一个糟糕的设计。在我看来，对象应该只在删除后出于法律要求而存档，而不是经常使用。
从物理上移除它们使一些事情变得更容易：级联删除、选择、数据库备份......
如何避免使用标记为已删除的对象？我需要什么设计才能从数据库中物理删除未使用的对象？有最佳实践吗？
上下文：基于 Java EE 和关系数据库的 OOP (DDD) 应用程序。
【问题讨论】：
标签： database database-design oop domain-driven-design
这是你的真实世界场景，发票和用户的意思是我认为的意思吗？
因为，我看不出如何在现实世界中删除发票。如果错误地向客户开具发票，该发票可能会作废，但不能删除物理数据，否则您将无法保留包含发票的信息。如果发票有效但与之关联的用户已终止，您仍然需要能够看到与发票关联的用户，否则您将丢失有关谁签发或批准发票或其他信息的信息。
就避免使用被删除的对象而言，我认为它不适用于这里，因为这些对象实际上都不能被删除。对于创建新发票或正在支付或收取的发票的用户，它们显然具有过期、作废、终止或无效状态，但它们肯定不会在不存在或被认为不存在的意义上被删除，因为它们显然在事务提交后的某个时间点确实存在。
【讨论】：
我在我的组织中与许多不同的人进行过多次讨论。我认为不应该删除用户帐户。如果只是为了能够轻松维护用户所做操作的记录的基本情况。我建议为用户设置一个状态，例如 active、on_hold、deactivated。然后，您需要做的就是根据需要停用用户帐户。当然，在“选择”用户时，您需要验证他们是否处于活动状态。如果用户返回组织，这也更容易。
【讨论】：
在数据库级别，您至少有两个可靠的选择。
1) 如果存在关联的发票，您不允许删除用户。
2) 当一个用户被删除时，所有与该用户相关的发票都会被删除。这可以通过参照完整性和级联删除最有效地完成。
我同意您的观点，即简单地将发票标记为已删除是不好的做法。如果它真的被删除了，它应该从数据库中出来（或者可能在某个地方存档）。
兰迪
【讨论】：
不确定是否需要保留发票？
如果是，那么您有多种选择。一种是让用户保留已删除的标志。如果您可以不知道原始用户是谁，那么创建一个“已删除用户”-用户对象。您可以将您的发票链接到该已删除用户。
如果答案是否定的，那么就删除所有引用已删除用户的对象。您可以手动执行此操作，也可以使用数据库的级联删除功能。
【讨论】：
为什么需要保留已删除的信息？通常，您需要保留它以用于审计、合规或法律要求。
通常，能够重现数据库的早期状态就足够了。数据库将支持这一点。
在大多数情况下，重要的是
如果确实不允许从数据库中删除它，可以随时将其放在归档表中，或者对数据库表进行分区，以便删除的对象不影响查询效率。
【讨论】：