Sql 表中数据的归档策略和限制

环境：Jboss、Mysql、JPA、Hibernate

我们的web应用程序将面向大量用户（~1000000），并且有许多子表存储用户特定的数据（例如个人、健康、论坛贡献…）

归档用户和用户特定信息的最佳做法是什么。 [a] 明智的做法是将存档的用户和用户特定信息移动到同一数据库中各自的表中（例如用户存档、用户论坛评论存档…）还是 [b] 请在原始表中用标记标记数据库条目，并仅查询未归档的条目

我们对User.loginid有一个独特的限制，如果用户通过1-[a]存档，您如何处理此要求（即，如果具有loginid“samuel”的用户被移动到存档表中，并且如果在原始表中添加了具有相同名称的新用户，您将如何防止这种情况发生。解决唯一密钥约束的最佳策略是什么

我们需要有选择地归档记录，并在必要时将其带回。您是否会依赖数据库工具？您是否会通过JPA实体模型公开的持久化API处理此问题

---

就个人而言，我会选择解决方案“[a]”

将内容拆分为两个表集（当前和存档）会使常见RDBMS概念的管理变得有点困难（例如：forum comment author将是指向用户表的外键…但不能让字段作为两个不同表的外键）

您可以采取折衷办法（users表使用解决方案“a”，所有其他表（如profile）都归档到一个双表（如每个解决方案“b”），但这会使代码变得不必要的复杂（在某些情况下，您必须查看未归档的表，在某些情况下仅查看归档的表，在某些情况下查看两者的联合）

解决方案A也可以轻松解决#2和#3需求。如果所有内容都在同一个表中，则用户名的唯一性很容易强制执行，而恢复存档用户只需在主用户表上翻转一点（存档=Y/N）

---

10%不算多，我怀疑性能方面的差异是否真的能证明额外的复杂性（以及bug风险）是合理的.

我会在表上放置一个存档标志，然后创建一个视图，以便在您不想查看存档记录时使用。这样，人们在应用我怀疑的存档标志时会更加一致。

首先，您希望能够对存档数据执行哪些操作？例如，除了第2点和第3点之外，让我们假设我在论坛中创建一些条目，然后我停止贡献并得到“存档”。我的贡献在活跃用户所做的贡献中是否仍然可见，或者它们是否也被存档？如果是，有人可以通过论坛访问哪些数据（即我的公共档案是否仍然可见）？对于“再次活跃”的人，您有什么样的政策？你预计活跃用户和非活跃用户的百分比是多少？我猜论坛贡献应该是可见的，因为论坛仍然有许多帖子（因为对特定于用户的论坛评论进行存档可能会使对话完全无用）。用户的公共配置文件不需要在存档后显示给其他用户。我可能希望存档那些在系统中不活动的用户（约占系统中总用户的10%）。再说一遍，我只是想知道如何正确解决这个问题，我的目的是尽可能减小表的大小，以便活动用户的查询速度更快。如果您计划有1000000个用户，我当然希望您为他们使用自动生成/标识数字PK，而不是像“samuel”这样的用户名。您会崩溃吗您的索引性能会将该字符串拖到任何地方。是的，我有一个自动生成的唯一id和User.loginid在系统中应该是唯一的。您是否建议您使用1-[b]而不是1-[a]来避免复杂性？是的。在存档标志上放置一个索引，以便SQL优化器可以快速删除存档用户（当你不需要它们时）你应该做得很好。