应该使用 id 或时间戳来确定数据库表中行的创建顺序吗？ （考虑到系统时钟设置不正确的可能性）

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

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

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

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

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

使用确定创建顺序id

• 优点：避免因系统时钟设置不正确而导致的问题。

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

使用确定创建顺序timestamp

• 优点：id列仅用于标识，并且timestamp正如它应该的那样，用于时间。
• 缺点：只有当每次向表中插入行时都知道系统时钟已正确设置时，此方法才可靠。如何才能确信每个插入的系统时钟都已正确设置？如果发现系统时钟在过去某个不精确已知的时间段内被错误地设置，那么如何修复表的状态呢？

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

使用顺序id会更简单，因为它可能（？）主键，因此有索引并且访问速度更快。鉴于你有user_id，您可以快速确认最近和之前的编辑。

使用timestamp也适用，但它可能是一个较长的条目，而且我们根本不知道它是否已建立索引，加上潜在的冲突。您正确地指出系统时钟可以改变......而顺序时钟id的不能。

鉴于您的更新：

由于很难了解您的具体要求，因此我将其作为特定项目对 200K+ 复杂文档和数百万次修订所需内容的证据。

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

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

我们最终所做的（经过大量策略/计划之后）是存储配置文件的连续版本，但它们是keyed 主要是 on an id field.

时间戳

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

其他捕获的数据

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

User_id
User_group
Action
Approval_id

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

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

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

可能值得查看数据浏览器的 Stack Overflow 表结构（相当复杂）。您可以在此处查看表结构：https://data.stackexchange.com/stackoverflow/query/new https://data.stackexchange.com/stackoverflow/query/new，来自元上的一个问题：SO 如何存储修订版本？ https://meta.stackexchange.com/questions/87224/how-does-so-store-revisions

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