版本控制数据库持久化对象，你会怎么样？ [英] Versioning Database Persisted Objects, How would you?

问题描述

（与版本化数据库模式无关）

(Not related to versioning the database schema)

与数据库连接的应用程序通常具有由来自多个表的数据组成的域对象。假设应用程序在CVS的意义上支持这些域对象的版本控制。

Applications that interfaces with databases often have domain objects that are composed with data from many tables. Suppose the application were to support versioning, in the sense of CVS, for these domain objects.

对于某些仲裁域对象，如何设计数据库模式来处理需求？任何分享的经验？

For some arbitry domain object, how would you design a database schema to handle this requirement? Any experience to share?

推荐答案

仔细考虑修订的要求。一旦你的代码库具有普遍的历史跟踪内置到操作系统中，它将变得非常复杂。 保险 承保 系统对此尤其糟糕，其中模式通常运行超过1000个表。查询也往往相当复杂，这可能会导致性能问题。

Think carefully about the requirements for revisions. Once your code-base has pervasive history tracking built into the operational system it will get very complex. Insurance underwriting systems are particularly bad for this, with schemas often running in excess of 1000 tables. Queries also tend to be quite complex and this can lead to performance issues.

如果历史状态真的只需要报告，请考虑实现当前状态事务系统与数据仓库结构挂在后面跟踪历史。 慢慢更改维度是一种用于跟踪历史状态的简单结构，比尝试嵌入自组织历史跟踪机制直接进入您的操作系统。

If the historical state is really only required for reporting, consider implementing a 'current state' transactional system with a data warehouse structure hanging off the back for tracking history. Slowly Changing Dimensions are a much simpler structure for tracking historical state than trying to embed an ad-hoc history tracking mechanism directly into your operational system.

此外，更改了数据捕获对于当前状态系统更简单，对现有记录进行更改 - 记录的主键不会更改，因此您不必将包含同一实体的不同版本的记录匹配在一起。有效的CDC机制将使得增量仓库加载过程相当轻量并且可能运行相当频繁。如果你不需要历史状态的最新跟踪（几乎，但不完全和矛盾），这可以是一个有效的解决方案，具有比直接构建到应用程序中的完整的历史跟踪机制更简单的代码库。

Also, Changed Data Capture is simpler for a 'current state' system with changes being done to the records in place - the primary keys of the records don't change so you don't have to match records holding different versions of the same entity together. An effective CDC mechanism will make an incremental warehouse load process fairly lightweight and possible to run quite frequently. If you don't need up-to-the minute tracking of historical state (almost, but not quite, and oxymoron) this can be an effective solution with a much simpler code base than a full history tracking mechanism built directly into the application.

这篇关于版本控制数据库持久化对象，你会怎么样？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！