database - 主键、UUID、RecordKey 表，天哪

Question

在开发内容管理系统时，我遇到了一些困难。回到我的数据模型，我注意到一些问题可能会随着时间的推移变得更加普遍。

即，我想维护用户记录修改的审计跟踪(更改日志)(甚至会记录用户记录修改)。由于包含任意数量的模块，我无法为我的主键使用按表自动递增字段，因为在尝试将它们的键维护在单个表中时，这将不可避免地导致冲突。

审计追踪将记录user_id、record_id、timestamp、action (INSERT/UPDATE/DELETE)和archive(旧记录的序列化副本)

我已经考虑了一些可能的解决方案，例如在应用程序逻辑中生成一个 UUID 主键(以确保跨数据库平台兼容性)。

我考虑过的另一种选择(我确信即使考虑这种方法，共识也会是负面的)是创建一个 RecordKey 表，以维护一个全局自动递增的 key 。不过，我确信有更好的方法可以实现这一点。

最终，我很想知道在尝试实现它时我应该考虑哪些选项。例如，我打算允许(至少开始)MySQL 和 SQLite3 存储选项，但我担心每个数据库将如何处理 UUID。

编辑以使我的问题不那么模糊:Would using global IDs be a recommended solution for my problem?如果是这样，使用 128 位 UUID(应用程序或数据库生成的)我可以在我的表设计中做些什么来帮助最大限度地提高查询效率？

Answer 1

好的，您碰壁了。而且您意识到实际上数据库设计存在问题。以后你会多次撞到同一堵砖墙。你的 future 看起来并不光明。你想改变它。好。

但是您还没有做的是，找出造成这种情况的真正原因。除非你这样做，否则你无法逃避可预测的 future 。如果你这样做得当，就不会有砖墙，至少不会有这堵特殊的砖墙。

首先，您在所有表上设置了Idiot 列以强制实现唯一性，而没有真正理解自然用于查找数据的标识符 和键。这就是砌墙的砖 block 。这是对需要考虑的问题的未考虑的下意识 react 。这就是您必须重新访问的内容。

1. 不要再犯同样的错误。重击 GUID 或 UUID，或 32 字节Idiot 列来修复你的NUMERIC(10,0) Idiot 列不会做任何事情，除了使数据库更胖，和所有 访问，尤其是连接，速度要慢得多。这堵墙将由混凝土砌 block 砌成，每小时都会撞到你。

2. 回头看看表格，并设计它们以成为数据库中的表格。这意味着您的起点是No Surrrogate Keys，没有Idiot 列。完成后，您将只有很少的Id 列。不是零，不是所有表，但很少。因此，墙上的砖 block 很少。我最近发布了一组详细的所需步骤，因此请引用:

   Link to Answer re Identifiers

3. 拥有一个包含所有表的审计“记录”的审计表的理由是什么？您喜欢遇到砖墙吗？您是否希望 db 的并发性和速度在 Insert hot-spot in one file 上成为瓶颈？

   审计要求已经在 dbs 中实现了 40 多年，因此您的用户有一些其他要求不会改变的可能性不是很高。不妨适本地做。审计表的唯一正确方法(对于 Rdb)是每个可审计的真实表有一个审计表。 PK 将是原始表 PK 加上 DateTime(复合键在现代数据库中很常见)。其他列将是 UserId 和 Action。该行本身将是之前的图像(新图像是主表中的单个当前行)。使用完全相同的列名。不要把它打包成一根巨大的绳子。

   如果您不需要数据(图像之前)，则停止记录。无缘无故地录制所有音量是非常愚蠢的。可以从备份中获得恢复。

4. 是的，单个 RecordKey 表是一个怪物。还有另一种有保证的单线程数据库方法。

不要对我的帖子使用react，我已经从你的评论中看出你有所有“正确”的理由做错事，并保持你的砖墙完好无损。我正在努力帮助你摧毁它们。仔细考虑几天再回复。