MySQL数据库活动日志:字段与表

Question

基本上，我正在创建一个个人财务跟踪系统。它想到的是，跟踪每个实例和事务最后一次编辑或更新的时间可能有一天是相关的信息。

现在，据我所见，有两种方法可以实现这样的东西：

1. 为我想要跟踪的所有表创建“更新”字段，然后让mysql为我更新这些字段(ON子句)
2. 创建一个完全独立的表来保存日志数据，然后使用触发器和事务更新该表。

现在看来，第一种方法的好处是保持简单和易于维护。但是，如果我突然决定让数据库中的每个日志都进行评审，这将如何影响性能。而且，对于存储在多个表中的相同数据，这也会与规范化(虽然不是很大程度上)相悖。

第二种方法将允许日志系统具有更大的灵活性，并可能实际上缩短检索某些数据所需的sql查询。但是，它将使模式更加复杂，因为必须创建两个额外的表(实际日志表和用于保存键的多到多关系表)并加以维护。另一方面，如果我想实现一个活动历史，这种方法很可能是唯一能够实现它的方法。

因此，我想知道每种方法的优点和缺点。由于第二个选项允许更多的灵活性，我正在考虑实现它，但我不确定性能问题。最后，可以归结为两种猜测：

这两种方法都有实现的实际例子吗？

和：

是否有任何研究、比较或其他资源可以说明哪些更有利于性能和“最佳实践”的方法？

Answer 1

这取决于您需要什么样的报告以及您当前的架构。

如果您只想知道最后的更新日期，那么有两个字段(创建日期和最后更新)就足够了。这是因为拥有单独的表不会提高性能，但会使代码更难维护。

如果您希望有更详细的内容，比如报告差异(更改了什么)和/或在每个事务上都有完整的更改日志(可能很少更新一个事务，对吧？)在这种情况下，您实际上必须有单独的表，因为否则它会膨胀您的桌子，降低性能。

根据我的经验，我会用单独的桌子。这是因为它将更容易维护--您的日志逻辑实际上将与其他所有内容分离，我认为有一天您将需要关于您的事务和完整事务历史的附加信息。

就性能而言，除非您的系统承受严重的负荷，否则您不会注意到任何可怕的差别。但是，由于您的系统是个人的，任何选择都可以，只是不要忘记适当的索引。

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