标签: database-versioning

您能否分享一下您如何在MongoDB中实现数据版本控制？(我问过关于Cassandra的类似问题.如果你有任何想法,哪个数据库更好,请分享)

假设我需要在简单的地址簿中对记录进行版本控制.(地址簿记录存储为平面json对象).我期待历史:

• 将很少使用
• 将一次性使用以"时间机器"的方式呈现它
• 单个记录的版本不会超过几百个.历史不会过期.

我正在考虑以下方法:

• 创建新的对象集合以存储记录的历史记录或对记录的更改.它将为每个版本存储一个对象,并引用地址簿条目.这些记录如下:

  {
   '_id': 'new id',
   'user': user_id,
   'timestamp': timestamp,
   'address_book_id': 'id of the address book record' 
   'old_record': {'first_name': 'Jon', 'last_name':'Doe' ...}
  }
  

  可以修改此方法以存储每个文档的版本数组.但这似乎是没有任何优势的较慢的方法.

• 将版本存储为附加到通讯簿条目的序列化(JSON)对象.我不确定如何将这些对象附加到MongoDB文档.也许是一个字符串数组.(使用CouchDB进行简单文档版本控制后建模)

我非常受Rich Hickey倡导的数据管理方法的启发,并在Datomic中实现,数据从未就地变异,所有版本始终保存和查询,时间是第一个 -阶级观念.

当然,有专门的数据库匹配该描述,如Git,或任何其他源控制系统.问题是,是否有任何(或多或少)通用DBMS-es的关系,图形,层次,文档或任何其他风格可以有效地用于,例如,电子商务Web应用程序.或者Datomic是唯一的选择呢？

在我们当前的开发工作流程中,我们引入了数据库迁移(使用Ruckusing)以使我们的开发人员的db模式保持同步.它工作得很好,使用起来非常简单,但现在我们已经切换到git作为VCS,我们正面临着数据库版本控制系统中的下一个问题.

在检查已经处于开发状态一段时间的分支时,可能会发生数据库模式与我来自的分支中的模式分歧很多.这在某些情况下会导致数据库冲突.从逻辑上看,似乎我们需要根据我们以前的分支运行迁移,但这可能会非常快速地复杂化,并且肯定会遇到一些问题.据我所知,没有一个分支感知的数据库迁移系统？

当切换到功能分支时增加了复杂性我们可能需要运行一些迁移而其他功能下降...技术上这似乎不可能使用我们当前的dbmigration脚本,是否有任何理智的替代方案？在非常活跃和分支的开发系统中是否有任何首选的数据库迁移方法？

以下是实现版本控制的可行策略(使用"example"作为示例文档类型):

有一个原始文档,其中类型字段名为example_original.

对文档的后续更改都具有类型example_change和example_original文档的id作为键.此更改还将带有时间戳.

保留一个类型为example_current的doc,它是example_original的结果,所有example_change都是"applied".新的example_change文档将自动应用于此文档.

查找特定版本将包括检索example_original文档并应用所需的更改(主要是某个时间戳,但也可能是一些更改).

我应该提一下,我的用例将涉及对原始的有限数量的更改.大多数更新将包含新的原始文档.虽然这是我目前的用例,但我也会对涉及许多变更会导致的问题感兴趣.

你在这种方法中看到了什么利弊？

我工作的软件系统是医疗计费系统,大量数据和数据表以及存储过程.

我正在阅读文章" 改进代码的12个步骤 ",而在Joel Test#2中则说:你能一步完成构建吗？

现在我想知道,这是否意味着部署构建(以便客户可以更新其部署).

现在我遇到的主要问题是你如何进行一步数据库更新？

目前,当我们对数据库进行更改时,会记录所有更改并将其添加到数据库更新脚本中,该脚本在创建部署到客户构建时会附加一个版本号.

有更简单的方法吗？一些脚本或应用程序在那里采用"之前和之后"查看数据库模式并创建像我提到的更新脚本？

或者这只是每个人都这样做的方式,我很难相信,但似乎有道理.

自动化系统可以减少错误,并大大加快部署构建时间,我很想知道如何这样做.

您能否分享一下您如何在Cassandra中实现数据版本控制的想法？

假设我需要在简单的地址簿中对记录进行版本控制.(地址簿记录存储为ColumnFamily中的行).我期待历史:

• 将很少使用
• 将一次性使用以"时间机器"的方式呈现它
• 单个记录的版本不会超过几百个.
• 历史不会过期.

我正在考虑以下方法:

• 将地址簿转换为超级列族并将多个版本的地址簿记录存储在一行(按时间戳)键为超级列.

• 创建新的超级列族以存储旧记录或更改记录.这种结构如下:

  {'地址簿行键':{'时间戳1':{'名字':'新名称','由'修改':'用户ID',},

  'time stamp2': {
          'first name': 'new name',
          'modified by': 'user id',
      },
  },
  

  Run Code Online (Sandbox Code Playgroud)

  '另一个地址簿行键':{'时间戳':{....

• 将版本存储为新ColumnFamilly中附加的序列化(JSON)对象.将版本集表示为行,将版本表示为列.(使用CouchDB进行简单文档版本控制后建模)

我一直在玩Entity Framework 4,使用模型驱动的方法从我的实体生成数据库脚本.这很好,但我不确定这在数据库版本控制时是如何工作的.我猜我是否想要使用活动记录类型迁移框架,我必须以相反的方式工作并从我的数据库生成我的实体？有没有办法使用模型驱动的方法并正确地版本化数据库？

您能否分享一下您如何在PostgreSQL中实现数据版本控制？(我已经问过关于Cassandra和MongoDB的类似问题.如果您有任何想法,哪个数据库更好,请分享)

假设我需要在简单的地址簿中对记录进行版本控制.为简单起见,地址簿记录存储在一个表中而没有关系.我期待历史:

• 将很少使用
• 将一次性使用以"时间机器"的方式呈现它
• 单个记录的版本不会超过几百个.
• 历史不会过期.

我正在考虑以下方法:

• 创建一个新的对象表来存储记录的历史记录,其中包含地址簿表的模式副本,并将时间戳和外键添加到地址簿表中.

• 创建一种架构较少的表来存储对通讯录记录的更改.这样的表包括:AddressBookId,TimeStamp,FieldName,Value.这样我只存储记录的更改,我不必保持历史表和地址簿表同步.

• 创建一个表来存储seralized(JSON)通讯簿记录或更改通讯簿记录.这样的表看起来如下:AddressBookId,TimeStamp,Object(varchar).同样这是架构,所以我不必保持历史表与地址簿表同步.(这是使用CouchDB进行简单文档版本控制后建模的)

对于我目前正在进行的项目,我需要实现对象版本控制.不幸的是,我需要保留每个对象的完整历史记录,因此像Papertrail这样的单个表解决方案很快就会变得无法管理.然而,我喜欢Papertrail的功能,我在一个解决方案中找不到每个模型的单独表格(例如acts_as_versioned).

• 能够存储来自控制器和模型的元信息
• 数据已序列化,因此架构更改不会修改版本表
• 遍历版本的强大方法
• 自动跟踪变更责任

还有Papertrail没有的一些功能可以奖励:

• 内置版本差异支持
• 差异而不是完整版本

我目前正在考虑让Papertrail为每个模型使用单独的表格,但是如果有现有的解决方案,我想节省这些努力.

更新: Vestal版本默认使用单个表,但通过为每个模型提供自定义版本类并使用ActiveRecord的"set_table_name"方法,我能够为每个模型创建单独的表.Vestal版本也内置差异支持,但其界面不如Papertrails强大.它也缺乏关联支持.

更新2: 由于papertrail似乎是一个更活跃的项目,我已经分叉了gem并添加了类似于版本的自定义类支持,现在允许为每个模型定义单独的表.我的分支在这里,但我希望它很快就会被拉入主项目库. https://github.com/benzittlau/paper_trail

我需要将版本放到SQL Server 2005数据库上,并从.NET应用程序中访问它们.我在想的是在数据库上使用名为"version"的扩展属性,当然值将是数据库的版本.然后,我可以使用SQL来实现此目的.我的问题是这听起来像一个好的计划还是有更好的方法将版本添加到SQL Server数据库？

让我们假设我无法使用表来保存元数据.