【问题标题】:Is there a version control system for database structure changes?是否有用于数据库结构更改的版本控制系统?
【发布时间】:2010-09-05 05:52:59
【问题描述】:

我经常遇到以下问题。

我正在对需要数据库中的新表或列的项目进行一些更改。我进行了数据库修改并继续我的工作。通常,我记得写下更改,以便可以在实时系统上复制它们。然而,我并不总是记得我改变了什么,我也不总是记得把它写下来。

所以,我推送到实时系统并得到一个明显的大错误,即没有NewColumnX,呃。

尽管这可能不是这种情况的最佳实践,是否有数据库版本控制系统?我不关心具体的数据库技术。我只想知道是否存在。如果它恰好可以与 MS SQL Server 一起使用,那就太好了。

【问题讨论】:

  • 根据我们的on-topic 指导,“有些问题仍然是题外话,即使它们属于上面列出的类别之一:...向我们提问的问题推荐或查找书籍、工具、软件库、教程或其他场外资源是题外话..."

标签: sql database oracle version-control


【解决方案1】:

看看oracle包DBMS_METADATA。

尤其是以下方法特别有用:

  • DBMS_METADATA.GET_DDL
  • DBMS_METADATA.SET_TRANSFORM_PARAM
  • DBMS_METADATA.GET_GRANTED_DDL

一旦您熟悉了它们的工作原理(很容易解释),您就可以编写一个简单的脚本,将这些方法的结果转储到可以置于源代码控制之下的文本文件中。祝你好运!

不确定 MSSQL 是否有这么简单的东西。

【讨论】:

    【解决方案2】:

    您可以在 Visual Studio 中使用 Microsoft SQL Server Data Tools 为数据库对象生成脚本,作为 SQL Server 项目的一部分。然后,您可以使用 Visual Studio 中内置的源代码管理集成将脚本添加到源代码管理。此外,SQL Server 项目允许您使用编译器验证数据库对象并生成部署脚本以更新现有数据库或创建新数据库。

    【讨论】:

      【解决方案3】:

      Redgate 有一个名为SQL Source Control 的产品。它与 TFS、SVN、SourceGear Vault、Vault Pro、Mercurial、Perforce 和 Git 集成。

      【讨论】:

        【解决方案4】:

        我有点老派,因为我使用源文件来创建数据库。实际上有 2 个文件 - project-database.sql 和 project-updates.sql - 第一个用于架构和持久数据,第二个用于修改。当然,两者都在源代码控制之下。

        当数据库发生变化时,我首先更新 project-database.sql 中的主模式,然后将相关信息复制到 project-updates.sql,例如 ALTER TABLE 语句。 然后我可以将更新应用到开发数据库,​​测试,迭代直到完成。 然后,签入文件,再次测试,然后应用到生产环境中。

        另外,我通常在db里有一个表——Config——比如:

        SQL

        CREATE TABLE Config
        (
            cfg_tag VARCHAR(50),
            cfg_value VARCHAR(100)
        );
        
        INSERT INTO Config(cfg_tag, cfg_value) VALUES
        ( 'db_version', '$Revision: $'),
        ( 'db_revision', '$Revision: $');
        

        然后,我将以下内容添加到更新部分:

        UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';
        

        db_version 仅在重新创建数据库时更改,db_revision 指示数据库偏离基线的程度。

        我可以将更新保存在它们自己的单独文件中,但我选择将它们混合在一起并使用剪切和粘贴来提取相关部分。需要进行更多的内务处理,即从 $Revision 1.1 $ 中删除 ':' 以冻结它们。

        【讨论】:

          【解决方案5】:

          Schema Compare for Oracle 是一款专门设计用于将更改从我们的 Oracle 数据库迁移到另一个数据库的工具。请访问下面的 URL 以获取下载链接,您可以在其中使用该软件进行全功能试用。

          http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

          【讨论】:

            【解决方案6】:

            MyBatis(以前的 iBatis)有一个schema migration,用于在命令行上使用的工具。它是用 java 编写的,但可以用于任何项目。

            要实现良好的数据库变更管理实践,我们需要确定几个关键目标。 因此,MyBatis Schema Migration System(或简称 MyBatis Migrations)旨在:

            • 使用任何新的或现有的数据库
            • 利用源代码控制系统(例如 Subversion)
            • 使并发开发人员或团队能够独立工作
            • 允许冲突非常明显且易于管理
            • 允许向前和向后迁移(分别进化、下放)
            • 使数据库的当前状态易于访问和理解
            • 尽管有访问权限或官僚作风,仍可进行迁移
            • 使用任何方法
            • 鼓励良好、一致的做法

            【讨论】:

              【解决方案7】:

              我想知道没有人提到基于 Java 的开源工具 liquibase,它应该适用于几乎所有支持 jdbc 的数据库。与 rails 相比,它使用 xml 而不是 ruby​​ 来执行架构更改。虽然我不喜欢特定领域语言的 xml,但 xml 非常酷的优势是 liquibase 知道如何回滚某些操作,例如

              <createTable tableName="USER"> 
                 <column name="firstname" type="varchar(255)"/>
              </createTable>
              

              所以你不需要自己处理这个

              也支持纯sql语句或数据导入。

              【讨论】:

              • 我们使用 liquibase,但我们对不同的信息使用 3 种不同的方法: 1. 结构(表、视图、...):历史变更日志 2. 代码(过程、pl/sql、函数) : 变更日志只有一个变更集标记为 runalways=true runonchange = true 3. 代码表,其他元“常量”存储在表中:与代码相同的方法,只有一个变更集,删除,插入所有信息
              • 对于 Java,我强烈建议这些天看看 flywaydb.org - 另请参阅本网站上的功能比较
              【解决方案8】:

              我强烈推荐SQL delta。当我完成对我的功能进行编码并将这些脚本检查到我的源代码控制工具中时,我只是使用它来生成差异脚本(Mercurial :))

              他们有 SQL 服务器和 Oracle 版本。

              【讨论】:

                【解决方案9】:

                ER Studio 允许您将数据库架构反转到该工具中,然后您可以将其与实时数据库进行比较。

                示例:将您的开发架构反转到 ER Studio - 将其与生产进行比较,它将列出所有差异。它可以编写更改脚本或自动推送它们。

                在 ER Studio 中拥有架构后,您可以保存创建脚本或将其保存为专有二进制文件并将其保存在版本控制中。如果您想回到该方案的过去版本,只需检查一下并将其推送到您的数据库平台。

                【讨论】:

                  【解决方案10】:

                  我们使用MS Team System Database Edition 取得了相当大的成功。它与 TFS 版本控制和 Visual Studio 或多或少无缝集成,使我们能够轻松地管理存储的过程、视图等。解决冲突可能会很痛苦,但是一旦完成,版本历史就完整了。此后,迁移到 QA 和生产非常简单。

                  公平地说,它是 1.0 版产品,但并非没有一些问题。

                  【讨论】:

                    【解决方案11】:

                    对于 Oracle,我使用 Toad,它可以将架构转储到多个离散文件(例如,每个表一个文件)。我有一些在 Perforce 中管理这个集合的脚本,但我认为它应该可以在几乎任何版本控制系统中轻松实现。

                    【讨论】:

                      【解决方案12】:

                      我会推荐两种方法中的一种。首先,投资 Sybase 的PowerDesigner。企业版。它允许您设计物理数据模型等等。但它带有一个存储库,允许您签入您的模型。每个新签入都可以是一个新版本,它可以将任何版本与任何其他版本进行比较,甚至可以与您当时数据库中的内容进行比较。然后它将显示每个差异的列表并询问应该迁移哪些......然后它会构建脚本来执行此操作。它并不便宜,但价格便宜两倍,投资回报率约为 6 个月。

                      另一个想法是打开 DDL 审计(在 Oracle 中工作)。这将创建一个包含您所做的每一个更改的表。如果您从上次将数据库更改移动到 prod 的时间戳查询更改到现在,您将获得已完成所有操作的有序列表。一些用于消除零和变化的 where 子句,例如 create table foo;其次是删除表 foo;你可以轻松地构建一个 mod 脚本。为什么要将更改保留在 wiki 中,这是双倍的工作。让数据库为您跟踪它们。

                      【讨论】:

                        【解决方案13】:

                        两本书推荐:Ambler 和 Sadalage 的“重构数据库”和 Ambler 的“敏捷数据库技术”。

                        有人提到 Rails 迁移。我认为它们工作得很好,即使在 Rails 应用程序之外。我在一个带有 SQL Server 的 ASP 应用程序上使用了它们,我们正在迁移到 Rails。您将迁移脚本本身检查到 VCS 中。 这是a post by Pragmatic Dave Thomas 的主题。

                        【讨论】:

                          【解决方案14】:

                          PLSQL Developer 是 All Arround Automations 的一个工具,它有一个用于存储库的插件,可以在 Visual Source Safe 中正常工作(但不是很好)。

                          来自网络:

                          版本控制插件提供了 PL/SQL Developer IDE >> 和任何支持 Microsoft SCC 接口规范的版本控制系统之间的紧密集成。 >>这包括最流行的版本控制系统,例如 Microsoft Visual SourceSafe、>>Merant PVCS 和 MKS Source Integrity。

                          http://www.allroundautomations.com/plsvcs.html

                          【讨论】:

                            【解决方案15】:

                            多年来,我断断续续地这样做了——管理(或尝试管理)架构版本。最佳方法取决于您拥有的工具。如果您能获得 Quest Software 工具“Schema Manager”,您将处于良好状态。 Oracle 有自己的劣质工具,也称为“模式管理器”(很混乱?),我不推荐。

                            如果没有自动化工具(请参阅此处有关 Data Dude 的其他 cmets),您将直接使用脚本和 DDL 文件。选择一种方法,记录它,并严格遵循它。我喜欢在任何给定时刻重新创建数据库的能力,所以我更喜欢对整个数据库(如果我是 DBA)或开发人员模式(如果我在产品中)进行完整的 DDL 导出-开发模式)。

                            【讨论】:

                              【解决方案16】:

                              如果您使用的是 SQL Server,则很难击败 Data Dude(即 Visual Studio 的数据库版)。一旦掌握了窍门,就可以轻而易举地在数据库的源代码控制版本和生产版本之间进行模式比较。只需单击一下,您就可以生成差异 DDL。

                              MSDN 上有一个指导性的 video,非常有帮助。

                              我知道 DBMS_METADATA 和 Toad,但如果有人能为 Oracle 想出一个 Data Dude,那生活会很甜蜜。

                              【讨论】:

                                【解决方案17】:

                                在没有用于表更改的 VCS 的情况下,我一直将它们记录在 wiki 中。至少那时我可以看到它何时以及为什么被改变。它远非完美,因为并非每个人都在这样做,而且我们有多个产品版本在使用,但总比没有好。

                                【讨论】:

                                  【解决方案18】:

                                  在版本控制器中创建初始的创建表语句,然后添加更改表语句,但不要编辑文件,只需按顺序命名更多更改文件,甚至作为“更改集”,这样您就可以找到所有更改具体部署。

                                  我能看到的最困难的部分是跟踪依赖关系,例如,对于特定的部署,表 B 可能需要在表 A 之前更新。

                                  【讨论】:

                                    【解决方案19】:

                                    我与编码并行编写我的数据库发布脚本,并将发布脚本保存在 SS 的项目特定部分中。如果我对需要更改数据库的代码进行更改,那么我会同时更新发布脚本。 在发布之前,我在一个干净的开发数据库(从生产中复制结构)上运行发布脚本并对其进行最终测试。

                                    【讨论】:

                                      【解决方案20】:

                                      在 Ruby on Rails 中,有一个 migration 的概念——一个用于更改数据库的快速脚本。

                                      您生成一个迁移文件,其中包含增加 db 版本的规则(例如添加一列)和降级版本的规则(例如删除一列)。每个迁移都有编号,并且有一个表跟踪您当前的数据库版本。

                                      向上迁移,您需要运行一个名为“db:migrate”的命令,该命令会查看您的版本并应用所需的脚本。您可以通过类似的方式向下迁移。

                                      迁移脚本本身保存在版本控制系统中——每当您更改数据库时,您都会签入一个新脚本,任何开发人员都可以应用它来将他们的本地数据库更新到最新版本。

                                      【讨论】:

                                      • 这是 Ruby 项目的选择。在 java 中最接近这种设计的是 mybatis 模式迁移。对于 .NET,等效值为 code.google.com/p/migratordotnet。它们都是海事组织这项工作的绝佳工具。
                                      【解决方案21】:

                                      有一个名为 Ruckusing 的 PHP5“数据库迁移框架”。我没用过,但examples 展示了这个想法,如果您使用该语言在需要时创建数据库,您只需跟踪源文件。

                                      【讨论】:

                                        【解决方案22】:

                                        大多数数据库引擎应该支持将您的数据库转储到文件中。无论如何,我知道 MySQL 确实如此。这只是一个文本文件,所以你可以将它提交给 Subversion,或者你使用的任何东西。对文件运行 diff 也很容易。

                                        【讨论】:

                                        • 是的,但是区分 SQL 文件不会为您提供必要的脚本来将您的 dev/prod 数据库从一个修订版升级到另一个修订版
                                        猜你喜欢
                                        • 2018-06-19
                                        • 1970-01-01
                                        • 2010-09-16
                                        • 1970-01-01
                                        • 1970-01-01
                                        • 2011-02-25
                                        • 1970-01-01
                                        • 2011-01-25
                                        • 2014-01-25
                                        相关资源
                                        最近更新 更多