MySQL 数据库事件日志 : fields vs table

Question

所以基本上我正在创建一个个人财务跟踪系统。碰巧的是，密切关注每个实例和事务的最后编辑或更新时间可能有一天会成为相关信息。

现在据我所知，有两种方法可以实现这样的事情:

1. 为我想要跟踪的所有表创建“更新”字段，然后让 mysql 为我更新这些字段(ON UPDATE 子句)

2. 创建一个完全独立的表来保存日志数据，然后使用触发器和事务更新该表

现在看来，第一种方法的好处是使事情变得简单且易于维护。但是，如果我突然决定获取数据库中的每个日志进行审查，这将如何影响性能。此外，对于存储在多个表中的相同数据，这会有点违背规范化(尽管不是很多)。

第二种方法将为日志系统提供更大的灵 active ，并且实际上可能会缩短检索某些数据所需的 SQL 查询。然而，这会使模式更加复杂，因为必须创建和维护两个附加表(实际日志表和用于保存 key 的多对多关系表)。另一方面，如果我想实现事件历史记录，这种方法可能是唯一能够做到这一点的方法。

因此，我想了解每种方法的更多优点和缺点。由于第二个选项允许更大的灵 active ，我正在考虑实现它，但我不确定性能问题。最后归结为两个问题:

Are there any real life examples where both approaches are implemented?

还有:

Are there any studies, comparisons or other resource that might shed some light on which is considered more performance friendly and "best practices" approach?

Answer 1

这取决于您需要哪种类型的报告以及您当前的架构。

如果您只想知道上次更新日期，那么有 2 个字段(创建日期和上次更新日期)就足够了。这是因为拥有单独的表不会带来任何性能提升，但会使您的代码更难以维护。

如果您想要更详细的内容，例如报告差异(更改的内容)和/或对每个事务有完整的更改日志(一个事务可能几乎没有更新，对吧？)，那就是另一回事了。在这种情况下，您实际上必须有单独的表，因为否则它会使您的表膨胀并降低性能。

根据我的经验，我会选择单独的 table 。这是因为它将更容易维护 - 您的日志记录逻辑实际上将与其他所有内容分开，我认为有一天您将需要有关交易和完整交易历史记录的附加信息。

就性能而言，除非您的系统负载严重，否则您不会注意到任何巨大的差异。但由于您的系统是个人的，任何选择都足够，只是不要忘记适当的索引。

请注意，我在这里做了很多假设，因此如果您想要更具体的信息，请提供您的实际架构和报告需求。我建议一些有关高可用性/性能的书籍，但它们不是针对您的特定需求，而是针对一般可用性/性能。