标签: database-versioning

在工作中,我们有4个人在几个不同的项目上一起工作.对于每个项目,我们每个都有一个我们工作的本地副本,然后有一个开发,暂存和实时部署,以及我们拥有的任何分支(我们使用subversion).我们的数据库是MySQL.

所以我的问题是,管理每个部署(以及开发人员本地副本)对数据库进行哪些修订的好方法是什么.现在,每个更改都会进入一个文本文件,该文件在名称中加上时间戳并放入项目下的文件夹中.说实话,这并不是很好.我需要一个能够帮助跟踪所应用内容的解决方案.

在阅读了很多关于保持页面更改历史记录或如何版本控制数据库中的记录(例如)的SO问题之后,我找不到真正优雅的解决方案来完成工作.

现在,让我们尝试尽可能清楚地解释我们需要什么,对于这个简单的修订系统,允许注册用户发布一些文章,其他用户提交那些文章的修订版,然后一些版主用户检查那些修订版.

MySQL数据库

该数据库包含一个文章表,其中包含以下简化字段:

ARTICLE(id, id_user, title, content, date);

要实现修订/历史版本,我想我们将有下表:

REVISION(id, id_article, revision_id_user, id_moderator, revision_date, 
         revision_title, revision_content, revision_description, revision_check);

与关系: ARTICLE 0,n <---> 1,1 REVISION

工作流程

• 用户创建一个ARTICLE,它被插入ARTICLE表中(太棒了!)

• 另一个用户对此进行了更新ARTICLE,此更新记录在REVISION表中,并为主持人用户排队.(revision_check=0).

• 主持人用户验证REVISION(revision_check=1),然后ARTICLE(content)获取REVISION(revision_content)值.

我的问题

• 这个工作流程似乎是一个很好的方法吗？因为,我看到一个错误:如果有几个REVISIONs ARTICLE:

  • 我们应该采取最后提交的内容REVISION还是原始内容ARTICLE？
  • 或者,我们是否需要阻止修订,因为REVISION在未检查最后一个时,不能提交其他内容.

• 有没有办法记录轻型版本？那么,是否可以REVISION通过SQL,PHP或js比较函数在表中插入更新的内容？如何像SO一样显示它呢？因为我担心REVISION桌子会很重.

• 额外奖励:怎么样？

任何想法,链接,源代码,插件(MySQL,PHP 5和JS/Jquery)都会受到极大关注.

有人可以解释迁移者(特别是流利者)的概念吗？

以下是我在这个问题上收集到的(可能是混乱的)事实:

• 它是一种通过版本控制最初创建然后维护数据库更新的方法.

• 第一个迁移(或数据库的初始版本)将包含所需的所有表,关系和属性(流畅地完成或在脚本中使用一大块sql).

• 如果要将更改推送到数据库,可以创建新的迁移方法(向上和向下),例如添加新表或修改字段.

• 要部署其中一个迁移,您将使用命令行指定包含迁移的dll,连接字符串和所需的版本.

如果您有一组相当复杂的数据模型,那么为所有这些模型创建迁移定义会不会相当困难和耗时？

我知道使用nHibernate/fluent,您可以轻松地为数据库生成表,而无需定义除模型和映射文件之外的任何内容.有没有办法使这个配置与Migrator/Versioning兼容？

当nhibernate/fluent负责生成数据库时,我不一定需要定义表的每个方面.它通过约定或映射文件完成.有了迁移器,我需要定义这个级别的细节吗？

我有一个应用程序,当应用程序第一次在计算机上运行时,Hibernate会创建我的所有表模式.这很好用.

然而,我想知道Hibernate是否有某种机制来保持数据库的版本控制,即当我运行不同版本的应用程序并且Hibernate从旧版本中找到不同的数据库模式时,Hibernate是否知道如何将一个模式迁移到另一个模式版本？考虑到Hibernate可以读取现有的模式并且可以将模式与映射描述进行比较,我认为这应该是可能的.但是我不知道如何在创建使用Liquibase/Flyway的更改脚本时告诉Hibernate迁移旧数据.

我可能没有用Google搜索正确的东西,因为Hibernate和版本控制会在审核和字段版本控制方面给你很多点击,但我更多地考虑了Liquibase/Flyway的版本控制.我从来没有考虑过这两者,但由于Hibernate不创建更新脚本而是直接操作数据库,我不知道如何使两者协同工作.

这是我第一次让Hibernate创建我的架构而不是编写我自己的脚本.我这样做是为了利用Hibernate Envers使得手动脚本创建更加繁琐.也许我错过了一些明显的东西.感谢您对此事的任何意见!

更新:我今天和Flyway的开发人员交谈,他告诉我他不会知道一个好的解决方案.也许什么都没有？

在阅读了几篇文章之后,我意识到开发团队中的数据库版本控制实际上非常重要.

到目前为止,dump whole database每次有更新时我都会使用一个简单的,如果只有一个表被更改,有时我们可以通过转储单个表然后重新导入来逃脱.不是最好的,但是效果很好,对于添加剂的改变,我们还没有任何打嗝.

现在,我将.mwb (Mysql Workbench diagram)文件保存在我正在处理的项目的git存储库中.然后我也用DBV了schema management,用git一起,每个分支基础上,项目被命名,它的工作相当不错.这允许我通过还原或回滚功能对原理图进行版本更改.

但是,表中包含的数据如何.怎么能保持这个？也许我最好坚持使用旧方法.我理解具有相同数据库结构但数据不同的项目,但是具有特定数据库数据的站点需要进行版本控制和管理.

另外,已部署的需要更改数据库的站点的基础如何,这是如何无缝的.有些人建议使用更新/更改脚本,并且可以使用默认值等.但是如果我在网站平台上进行了更改,需要更改每个网站数据库,并保持数据完好无损呢？

我正在研究许多Delphi应用程序,当发布新版本和用户选择安装其他模块时,需要在现场升级自己的数据库结构.应用程序使用各种嵌入式数据库(目前是DBISAM和Jet,但这可能会改变).

在过去,我使用DBISAM使用用户版本号完成此操作,而不是可以存储在每个表中.我发送了一组额外的空数据库文件,并在启动时使用FieldDefs比较每个表的版本号,以便在必要时更新已安装的表.虽然这有效但我发现必须运送数据库的备用副本并且更新版本的DBISAM已经改变了表重组方法,因此无论如何我都需要重写它.

我可以看到两种实现方法:使用数据库存储版本号并使用DDL脚本从旧版本获取更新版本或在应用程序内存储数据库结构的引用版本,比较启动时对数据库的引用up,并让应用程序生成DDL命令来升级数据库.

我想我可能要实现两者的一部分.我不希望每次应用程序启动时应用程序都将数据库与引用结构区分开来(太慢),因此我需要一个数据库结构版本号来检测用户是否使用了过时的结构.但是,我不确定我可以信任预先编写的脚本来进行结构升级,因为过去数据库可能已经部分更新,或者用户可能自己更改了数据库结构,所以我倾向于使用实际更新的参考差异.

研究这个问题我发现了几个数据库版本控制工具,但它们似乎都是针对SQL Server的,并且是在实际应用程序之外实现的.我正在寻找一个可以紧密集成到我的应用程序中的流程,它可以适应不同的数据库需求(我知道我必须编写适配器,自定义后代类或事件代码来处理各种DDL的差异数据库,这不会打扰我).

有没有人知道任何现成的东西,或者没有做到这一点,有没有人有任何想法:

1. 在应用程序中存储通用关系数据库结构的引用版本的最佳方法.

2. 将引用与实际数据库区分开来的最佳方法.

3. 生成DDL以更新数据库的最佳方法.

在公开不同的API版本时,如何处理存储和检索可能具有不同结构的数据？

假设我们有两个API版本; V1和V2.V1和V2都在' https://api.com/message '上有一个POST端点,它将根据传递的数据在数据库中创建一条消息,如:

{
    DOB: '2014-12-01'
}

在V1中,所需数据与V2不同,因为在V2中我们决定将DOB从格式为'YYYY-MM-DD'的字符串更改为整数时间戳,例如1284723728323

在这种情况下,当我们使用V2 API从调用中保存数据时,DOB字段将是一个整数,但是当从调用保存到V1时,它将是一个非常不同格式的字符串.

通过API的每次迭代,我们可以修改底层数据的许多方面.调用较旧的API版本将导致存储的数据对于其他版本的API不正确.

是否有一种优雅的方式来处理需要不同格式/结构数据的不同API版本？

我已经到了这一点,我意识到我必须开始对数据库模式进行版本控制并进行更改.因此,我阅读了有关该主题的现有帖子,但我不知道如何继续.

我基本上是一个单人公司,不久前我甚至没有为我的代码使用版本控制.我在Windows环境中使用Aptana(IDE)和SVN(使用Tortoise).我从事PHP/mysql项目.

版本化我的数据库模式的有效且充足(没有过度杀伤)的方法是什么？

我在一些项目中确实有一两个自由职业者,但我不希望进行大量的分支和合并.所以基本上我想跟踪我的代码修订的并发模式.

[编辑] 瞬间解决方案:目前我决定只要我提交一个标签(稳定版本),我将只生成一个模式转储加上一个必要的初始数据.在目前阶段,这对我来说似乎已经足够了.[/ edit]

[edit2]此外我现在还使用了名为incrementments.sql的第三个文件,其中我将所有更改与日期等相关联,以便在一个文件中轻松跟踪更改历史记录.我不时将更改集成到另外两个文件中并清空increments.ql [/ edit]

我们有一个购物车,如下图所示,设置运行良好,除了一个致命的缺陷.如果您下订单该订单与产品相关联,那么如果我在您购买产品后更新产品,我就无法向您展示您希望产品在购买时的样子(包括价格).这意味着我们需要版本控制.

我目前的计划是,在创建新产品或变体或编辑现有产品或变体时,在数据库中创建产品或变体的副本.购买时,将订单链接到版本,而不是产品.

这似乎相当简单,除了我可以看到的,我们不需要版本的唯一事情是类别(因为没有人关心它的类别).所以我们需要版本:

• 制品
• 变种
• 每个版本的键 - >值对属性
• 图像

我目前的想法是,

注意: 创建产品时,也会创建默认变体,但无法删除.

• 创建产品时
  • 将产品插入产品表中.
  • 创建默认变体
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列

• 编辑产品时
  • 将产品更新到产品表中.
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将所有产品变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列
  • 将所有variant_image_links复制到variant_Image_link_version表中
    • 将当前variant_id列替换为variant_version_id列

• 添加变体时
  • 将变体添加到变体表中.
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将所有产品变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列

• 编辑变体时
  • 更新变体表中的变体.
  • 将产品复制到products_versions表中
    • 使用product_id列替换当前id列
    • 添加id列
  • 将所有产品变体复制到variants_versions表中
    • 用variant_id列替换当前id列
    • 添加id列
    • 将product_id列替换为product_version_id列
  • 将所有variant_image_links复制到variant_Image_link_version表中
    • 将当前variant_id列替换为variant_version_id列

所以最终结构看起来像全尺寸

现在这一切看起来都很棒,除非它看起来像是一堆重复数据,例如,如果我们更新产品,我们会复制变体,即使它们插入后也不会更新.此外,这似乎很多工作.

有没有更好的方法呢？

我想向我的 MongoDB 中的文档添加版本控制。在 MongoDB 中是否有版本控制的最佳实践？在我的 MongoDB 中对文档进行版本控制的最简单方法是什么？