版本控制数据库持久对象，你会如何? [英] 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屋！