我正在开发一个跟踪和处理工作单/票据的应用程序。每个故障单都链接到通过外键创建/拥有故障单的用户，该外键可以对MySQL中的任何更改进行级联。显然，如果用户出于某种原因删除了他们的帐户，我们仍然希望记录他们的门票及其基本信息。
实现这一目标的第一种方法是在users表中有一个列，表示它们是处于活动状态还是非活动状态，即是否已删除。这样，当他们关闭/删除他们的帐户时，他们只是翻转此值，然后无法访问该应用。
我的另一个想法是在删除帐户时将用户记录移动到已删除的用户表。这种方式可以保持用户表的性能最佳，当它变大时可能是一个巨大的交易，但添加额外的查询来移动记录。
显然，部分原因可能是偏好，但我对性能方面感兴趣。基本上问题是选择查询如何与插入查询进行比较，以及通过将插入查询（将记录移动到已删除的用户表）添加到混合中，整体性能会在何时增加？
答案 0 :(得分：10)
在users表中有一个列，表示它们是处于活动状态还是非活动状态，即是否已删除。
好。
我的另一个想法是将用户记录移动到已删除的用户表
坏。您现在有两个连接：用户到故障单和前用户到故障单。这是一种不必要的复杂性。
当它变大时，可能是一个巨大的交易，
如果，“大”，你的意思是数百万用户，那么你是对的。 但是，如果“大”，则表示成千上万的用户，您将无法衡量太多差异。
和。如果您确实在未来确实存在可衡量的减速，您可以使用“物化视图”之类的内容自动创建“活跃”用户的子集视图/表。
显然，部分原因可能是偏好，
不是真的。停用（但不删除）用户有许多优点，没有真正的缺点。
有很多级别的活动 - 安全锁定（但未禁用） - 暂时禁用 - 委托给其他用户。很多很多状态都在变化。删除的理由很少。没有理由“搬到另一张桌子”。
如何通过将插入查询（将记录移动到已删除的用户表）添加到混合中，将select查询与插入查询进行比较，以及在什么时候整体性能会提高？
只有您可以针对您的表，索引，服务器和交易组合来衡量这一点。没有通用的答案。
答案 1 :(得分：1)
在我看来，将用户标记为已删除是更好的方法。第二种方法，使用新表，将导致您引用用户表的每个表中的更改。您应该有新的外键到“已删除的用户表”。这将更改此表中选择行的所有查询。
正如您所写，应用程序是关于票证的，逻辑上大多数查询都是关于选择和编辑票证。所以影响将在这个表上，我不认为你对用户提出了很大的疑问。
对“用户”表进行优化并对“票证”表进行更复杂的查询将无法获得回报。