如何维护数据库审核？

Question

我使用的是MySQL数据库(使用Django )。我希望维护类似于StackOverflow、Quora、Wikipedia等的数据库审计。这些网站维护数据库中更改的修改，以便用户/管理员所做的更改能够被恢复。

在研究了StackOverflow和Quora修订的数据库设计之后，我理解了两种方法-

StackOverflow

创建一个重复表，以保存数据库中所做更改的日志。对于每个条目，记录进行此更改的更改、时间戳和管理员/用户。使用这些条目查找差异并恢复到任何点。因此，将修订的历史记录保存在单独的PostHistory表中。

Quora

与其为数据库中的每个表创建单独的表，不如将这样的表用于审计。

• id -订正id
• 数据库表的scope_id - id
• scope_type -问题、主题、用户
• 数据库表中问题/主题/用户的item_id行id
• 事件-编辑、添加、恢复、删除
• user_id -谁触发了这一事件
• 时间戳
• serialized_item_column - json格式的序列化数据

然后，序列化的数据可以用于计算差异和还原特定的条目。

在诸如wiki/SO这样的众包平台中，多个用户/管理员可以进行更改，

• 这两种数据库设计中哪一种更好？
• 如果我对每个表使用一个重复表来进行修订，即一个用于当前值，另一个用于所有以前的修订，那么对于一个拥有数百万条目和更多修订的网站来说，这是一种可伸缩的方法吗？

Answer 1

站在你的前辈的肩上。

如果我使用重复的表格，这是一个具有数百万条目和更多修订的网站的可伸缩方式吗？

“重复的桌子”？计划A:一张包含所有修订的表格。计划B: 2张表，一张带有现值，一张带有所有以前的修订。计划C(非常糟糕)：每次修订一张表格。

这两种数据库设计中哪一种更好？

一旦你完成了定义“更好”的练习，你就会半途而废。

如果模式更改，如何在基于json的审计中更改模式？

这听起来像是问题的另一个维度--模式更改的跟踪。这本身就是一项非常艰巨的任务。随着模式的更改，JSON添加/删除额外的“字段”没有问题。但是，如果一个表被拆分，那么JSON就会变得更加棘手。您可能需要特殊的代码桥梁的差距。

底线

既然你似乎才刚刚开始这一努力，我建议你掷一枚硬币来决定使用哪一枚硬币。

但是..。计划在6个月内重新考虑该决定。到那时，您将有足够的经验的代码，以有一些感觉，它是否会对你想要的方向工作。

当然，6个月后换衣服会很痛苦(非常痛苦)。但12个月后，这将是“不可能的”。您可能会决定修补所选的模式，而不是切换到其他模式。

或者，您可能会分拆另一家公司来使用其他数据库模式。一个预测:你会发现“草不更绿”，第二家公司会倒闭。