在我的一个站点上，我有一个主用户表，其中包含每个用户的唯一用户 ID、电子邮件地址、密码等。
我需要开始跟踪很多与每个用户相关的二进制标志，例如他们是否确认了他们的电子邮件，他们是否发布了消息，他们是否升级了他们的帐户，他们是否做过 X，他们是否做过Y等。
这些标志中的每一个都是简单的“0”（假）或“1”（真），并且基于这些标志，我的网站向用户显示或执行不同的操作。
我的问题是，将这些二进制标志添加到主用户表或为二进制标志或其他东西创建一个单独的表是否更有意义？
请尝试解释您的推理（以及您的方法的优点），以便我了解您的来源。
所有这些标志都需要存储还是可以计算？例如，如果用户没有发布任何消息，则可以通过查询 MESSAGE 表轻松确定。
物理存储“可计算”标志是多余的，并且可能导致数据不一致。例如，如果用户添加了一条消息但您的应用程序中的错误阻止了标志更新怎么办？出于性能原因，这种“非规范化”可能是合理的，但只有在您测量了实际数据量和代表性工作负载的性能后才能做出此决定。
OTOH，一些标志可能是“真实的”（例如用户是否已确认电子邮件）。如果这些标志是相对静态的（即您在设计数据模型时预先知道它们），则将它们作为简单的布尔（或等效）字段直接存储在 USER 表本身中。
仅当您需要具有相当大的运行时灵活性时，才考虑使用与 USER 表处于 N:1 关系的单独 FLAG 表。这是一种EAV。
将它们保持在一起和分离它们具有优势：如果将标志放在Users表中，通过对用户 ID 的简单查询，您可以获得有关该用户的所有信息，而不是使用连接来检索它们。
另一方面，将它们放在单独的表上会使它们与表上的数据“逻辑上”分开Users，这可能是完全不相关的（即使它们都谈论用户），因此具有更清晰的数据库结构。
另一件需要考虑的事情是您必须多久更改和检索此类数据：例如，如果您只在登录时需要它们，那么您可能希望将它们保存在同一张表上并一次获取所有登录数据；相反，如果您必须反复更改它们，那么您的选择应该在另一张桌子上进行。
也就是说，无论如何我都会选择两个表的解决方案，但这正是我喜欢在 DB 模式中看到它们的方式。