我将开发一个网站，用户可以在其中编辑以前提交的表单数据。我被要求做的是通过数据库中某种形式的版本控制系统跟踪所有编辑。我还不完全确定我将要使用的数据结构，但我正在尝试考虑这种版本控制系统的最佳方法。如果我假设数据库中的大多数表都具有可编辑数据，那么我需要提出一种合理且可扩展的方法。
目前我正在考虑一种简单的方法，而不是使用已编辑的数据更新行，而是在同一个表中创建一个新行。检索要显示的数据时，查询将根据最新的带时间戳的行（或某种形式的标志来检索数据，以指示版本顺序）。我可以遇到的一个问题是，对一个表的更改应该级联到相关表。使用InnoDB实现引用完整性可能无法使用此方法，因为将生成新的行/ ID。这可能需要另一种方法，我设置触发器，这些触发器在UPDATE语句上激活，并处理所有必要的交叉表数据更改。这可以采用仅创建带有额外列的表镜像来记录日期/版本号的形式。
如果有人对处理此类事情的一般方法有任何建议，我将非常感谢您的建议！
答案 0 :(得分：3)
这是一个很好而深刻的问题，如果不了解您将要处理的工作负载类型，要执行的实际查询（您应该对其进行分析！），要进行版本控制的各种信息，以及等等。
但至于一般方法，我会从一个简单的解决方案开始，你可以试验和基准测试。从这个特定的案例研究中，开发一个更加健壮的案例，您可以使用从最初尝试中学到的经验教训。
这是一个很好的例子：Database - Data Versioning
存在其他示例，并且阅读您的问题我认为您不仅需要审计跟踪，还需要实际信息（能够及时返回特定版本）。
在回答您的具体问题时，无论是否使用触发器，我都会采用不同的方法：在 Transactional-update / delete 等存储过程中使用您的业务逻辑，以后可以更新，使更复杂。为什么？因为它在“一个地方”并且没有任何东西可以解决它，并且因为触发器与表和原子操作（更新，删除）而不是事务更相关!!
对于性能，我只是将活动记录标记为更新存储过程（或高级语言过程）的一部分，而不是查询最新版本。
答案 1 :(得分：0)
触发器是一个很好的解决方案。我本人更喜欢将这种类型的逻辑包含在我的应用程序中，因此我将其保存在应用程序的业务逻辑层中。