3

数据库表用于存储对文本文档的编辑更改。

数据库表有四列： { id, timestamp, user_id, text}

每次用户编辑文档时，都会向表中添加一个新行。新行具有自动递增的 id，以及与数据保存时间相匹配的时间戳。

为了确定用户在特定编辑期间进行了哪些编辑更改，将text响应他或她的编辑而text插入的行中的 与先前插入的行中的 进行比较。

要确定哪一行是先前插入的行，可以使用id列或timestamp列。据我所知，每种方法都有优点和缺点。

使用确定创建顺序id

  • 优点：不受错误设置系统时钟导致的问题的影响。

  • 缺点：似乎是对id列的滥用，因为它为列规定了除身份之外的含义id。管理员可能出于任何原因（例如，在数据迁移期间）更改一组 id 的值，因为只要它们是唯一的，这些值是什么并不重要。然后无法再确定行的创建顺序。

使用确定创建顺序timestamp

  • 优点：该id列仅用于标识，而timestamp用于时间，因为它应该是。
  • 缺点：只有在每次将行插入表时都知道系统时钟已正确设置时，此方法才可靠。怎么能相信每个插入的系统时钟都正确设置了呢？如果发现系统时钟在过去某个不准确的时期被错误地设置，那么如何修复表的状态？

我寻求一个强有力的论据来选择一种方法而不是另一种方法，或者描述另一种比我正在考虑的两种方法更好的方法。

4

3 回答 3

1

使用标识。这很简单并且有效。

唯一需要注意的是，如果您经常从存储转发服务器添加行，那么可以稍后添加行，但应将其视为较早添加

于 2012-11-21T03:43:01.713 回答
1

使用顺序id会更简单，因为它可能是（？）主键，因此被索引并且访问速度更快。鉴于您拥有user_id，您可以快速断言上次和之前的编辑。

使用timestamp也是适用的，但它可能是一个更长的条目，而且我们根本不知道它是否被索引，以及发生冲突的可能性。您正确地指出系统时钟可以改变......而序列id的不能。

鉴于您的更新：

由于很难看出您的确切要求是什么，因此我将其作为特定项目需要 200K+ 复杂文档和数百万次修订的证据。

根据我自己的经验（为 60 多名全职研究人员组成的内部团队构建一个完全可审计的文档/分析系统）。我们最终使用了一个id和许多其他字段（包括timestamp）来提供审计跟踪和完整版本控制。

我们为每个配置文件构建的系统有 200 多个字段，因此对文档进行版本控制远比为每个配置文件存储一块更改的文本/内容要复杂得多；然而，每个配置文件都可以被编辑、批准、拒绝、回滚、发布，甚至可以导出为 PDF 或其他格式作为一个文档。

我们最终做的（经过大量策略/计划）是存储配置文件的顺序版本，但它们主要在字段上键入id。

时间戳

时间戳也被捕获作为辅助检查，我们通过使用定期检查时间对齐并在必要时更正它们的 cron 脚本确保保持系统时钟准确（在服务器集群中）。我们还使用Ntpd来防止时钟漂移。

其他捕获的数据

为每次编辑捕获的其他数据还包括（但不限于）：

User_id
User_group
Action
Approval_id

还有其他表格满足内部要求（包括为文档自动生成的注释） - 因为一些配置文件编辑是使用来自机器人的数据完成的（使用 NER/机器学习/AI 构建），但需要获得其中之一的批准可以发布编辑/更新之前的团队。

还保存了所有用户操作的操作日志，以便在审核时，可以查看单个用户的操作 - 即使他们没有执行此类操作的权限，它仍然被记录下来.

关于迁移，我不认为这是一个大问题，因为您可以轻松地在移动/转储/传输数据中保留 id 序列。也许唯一的问题是您是否需要合并数据集。在那种情况下，您总是可以编写一个迁移脚本 - 所以从个人角度来看，我认为这个缺点有所减少。

可能值得查看那里的数据浏览器的 Stack Overflow 表结构（相当复杂）。您可以在此处查看表结构：https ://data.stackexchange.com/stackoverflow/query/new ，它来自关于元的问题：SO 如何存储修订？

作为一个修订系统，SO 运行良好，降价/修订功能可能是一个很好的例子。

于 2012-11-21T03:46:46.870 回答
1

或者添加另一列，其唯一目的是记录编辑顺序。我建议您不要为此使用日期时间。

于 2012-11-21T03:49:37.177 回答