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