【问题标题】:Data Versioning Advice数据版本建议
【发布时间】:2010-03-07 17:44:47
【问题描述】:

我将开发一个网站,用户将有机会编辑以前提交的表单数据。我被要求做的是通过数据库中某种形式的版本控制系统跟踪所有编辑。我仍然不完全确定我将使用的数据结构,但我正在尝试为这种类型的版本控制系统考虑最佳方法。如果我假设数据库中的大多数表都有可编辑的数据,那么我需要为此提出一种明智且可扩展的方法。

目前,我正在考虑一种简单的方法,即在同一个表中创建一个新行,而不是使用已编辑的数据更新一行。在检索数据以供显示时,查询将根据最新的时间戳行(或某种形式的标志来指示版本顺序)检索数据。我在这里可能遇到的一个问题是,当对一个表的更改应该级联到相关表时。使用 InnoDB 强制引用完整性可能不适用于这种方法,因为会生成新的行/id。这可能需要另一种方法,在该方法中我设置在 UPDATE 语句上激活并处理所有必要的交叉表数据更改的触发器。这可以采取仅创建具有额外列以记录日期/版本号的表的镜像的形式。

如果有人对处理此类事情的一般方法有任何建议,我将不胜感激!

【问题讨论】:

标签: database database-design


【解决方案1】:

这是一个很好且深刻的问题,如果不了解您将处理的工作负载类型、要执行的实际查询(您应该对它们进行分析!)、要版本化的各种信息以及以此类推。

但对于通用方法,我将从一个简单的解决方案开始,您可以对其进行试验和基准测试。从该特定案例研究中,开发一个更可靠的案例,并使用从最初尝试中吸取的经验教训来详细说明。

这里有一个很好的例子:Database - Data Versioning

存在其他示例,阅读您的问题,我相信您不仅需要审计跟踪,还需要实际信息(以便能够及时返回到特定版本)。

针对您的具体问题,是否使用触发器,我会以不同的方式处理它:将您的业务逻辑放在 Transactional-update/delete 等的存储过程中,您可以稍后对其进行更新和使更复杂。为什么?因为它在“一个地方”,没有任何东西可以绕过它,而且因为触发器更多地与表和原子操作(更新、删除)而不是事务相关联!!

为了性能,我只是将活动记录标记为更新存储过程(或就此而言的高级语言过程)的一部分,而不是查询最新版本。

【讨论】:

    【解决方案2】:

    触发器是一个很好的解决方案。我自己更喜欢将这种类型的逻辑包含在我的应用程序中,因此我将其保留在我的应用程序的业务逻辑层中。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-28
      • 1970-01-01
      • 2015-11-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多