所以基本上我正在创建个人财务跟踪系统。事实上，在上次编辑或更新每个实例和交易时，要密切关注某天可能会提供相关信息。
现在我可以看到有两种方法可以实现这样的目的：
为我要跟踪的所有表创建“更新”字段，然后让mysql为我更新这些字段（ON UPDATE子句）
创建一个完全独立的表来保存日志数据，然后使用触发器和事务更新
现在看来，第一种方法的好处是保持简单易维护。但是，如果我突然决定让数据库中的每个日志都进行审核，这将如何影响性能。此外，这种情况也会与存储在多个表中的相同数据相反（不是很多）。
第二种方法可以为日志记录系统提供更大的灵活性，并且可能实际上缩短了检索某些数据所需的sql查询。但是，它会使架构更复杂，因为必须创建两个额外的表（实际的日志表和用于保存键的多对多关系表）并进行维护。另一方面，如果我想要实现活动历史，这种方法可能是唯一能够做到这一点的方法。
因此我想知道每种方法的更多优点和缺点。由于第二个选项允许更多的灵活性，我正在考虑实施它，但我不确定性能问题。最后，它归结为两个猜测：
这两种方法都有真实的例子吗？ 执行吗？
和
是否有任何研究，比较或其他资源可能会流失 一些亮点被认为更加性能友好和“最好 实践“方法？
答案 0 :(得分：0)
这取决于您需要什么类型的报告以及您当前的架构。
如果您只想知道上次更新日期，那么拥有2个字段（创建日期和上次更新）就足够了。这是因为拥有单独的表格不会提高任何性能，但会使您的代码难以维护。
这是另一个故事，如果你想要更精细的东西，比如报告差异（改变了什么）和/或每个事务都有完整的更改日志（对一个事务可能很少更新，对吧？）。在这种情况下，你实际上必须有单独的表，否则它会使你的表膨胀并降低性能。
根据我的经验，我会选择单独的表格。这是因为它更容易维护 - 您的日志记录逻辑实际上将与其他所有内容分开，我想有一天您需要有关交易和完整交易历史记录的其他信息。
就性能而言，除非您的系统承受严重负担，否则您不会注意到任何强大的差异。但是，由于您的系统是个人的，任何选择都足够了，只要不要忘记正确的索引。
请注意，我在这里做了很多假设，所以如果您想要更具体的内容，请提供您的实际架构和报告需求。我建议一些有关高可用性/性能的书籍，但它们不是针对您的具体需求，而是针对一般可用性/性能。