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

【问题标题】：archiving strategies and limitations of data in a table表中数据的归档策略和限制
【发布时间】：2010-04-06 05:39:09
【问题描述】：

环境：Jboss、Mysql、JPA、Hibernate

我们的网络应用程序将满足大量用户（约 1,000,000）的需求，并且有很多子表存储用户特定数据（例如个人、健康、论坛贡献......）。

归档用户和用户特定信息的最佳做法是什么。 [a] 将归档的用户和用户特定信息移动到同一数据库中的各自表中是否明智（例如 user_archive、user_forum_cmets_archive ...）或 [b] 您是否只在原始表中用标志标记数据库条目，只查询未归档的条目。
我们对 User.loginid 有一个独特的约束，如果用户通过 1-[a] 存档（即如果登录 ID 为“samuel”的用户被移动到存档表中并且如果在原始表中添加了具有相同名称的新用户，您将如何防止这种情况发生。解决唯一键约束的最佳策略是什么。
我们需要有选择地归档记录并在必要时将其恢复，您是否会依赖数据库工具，是否会通过 JPA 实体模型公开的持久性 API 来处理此问题。

【问题讨论】：

首先，您希望能够对归档数据执行哪些操作？除了第 2 点和第 3 点之外，假设我在论坛中创建了一些条目，后来我停止贡献并被“归档”。我的贡献在活跃用户的贡献中是否仍然可见，或者它们是否也被归档？如果是，有人可以通过论坛访问哪些数据（即我的公开资料仍然可见）？对于人们“重新活跃起来”，你们有什么样的政策？您预计活跃用户与非活跃用户的百分比是多少？
我想论坛贡献应该是可见的，因为论坛仍然有很多帖子（因为特定于用户的论坛 cmets 存档，可能会使对话完全无用）。用户的公开资料不需要在存档后显示给其他用户。我可能想归档那些在系统中不活跃的用户（大约占系统总用户的 10%）。同样，我只是在寻找有关解决此问题的正确方法的想法，并且我的目的是使表大小尽可能小，以便活跃用户的查询更快。
如果您计划拥有 1,000,000 个用户，我当然希望您为他们使用自动生成/身份数字 PK 而不是像“samuel”这样的用户名。你把那个字符串拖到任何地方都会破坏你的索引性能。
是的，我有一个自动生成的唯一 ID，并且 User.loginid 在系统中应该是唯一的。

【解决方案1】：

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

将内容拆分为两个表集（当前和存档）会使事情在常见的 RDBMS 概念方面有点难以管理（例如：论坛评论作者将是指向用户表的外键......但你不能让一个字段充当两个不同表的外键）。

您可以妥协（用户表使用解决方案“a”，所有其他表（如配置文件）都被归档到一个双表中，就像每个解决方案“b”一样）但这会使您的代码变得不必要的复杂（在某些情况下）在某些情况下您必须查看未存档的情况，在某些情况下仅存档，在其他情况下将两者结合）。

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

10% 并不多，我怀疑性能方面的差异是否真的能证明额外的复杂性（和错误的风险）是合理的。

【讨论】：

【解决方案2】：

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

【讨论】：