是否有用于数据库结构更改的版本控制系统？

我经常遇到以下问题。

我正在对项目进行一些更改，这些更改需要数据库中的新表或新列。我进行数据库修改并继续我的工作。通常，我记得记下更改，以便可以在实时系统上复制它们。但是，我并不总是记得自己所做的更改，也并非总是记得写下来。

因此，我推动了实时系统，并收到了一个很大的明显错误，那就是没有NewColumnX，呃。

无论这可能不是这种情况的最佳实践，是否都存在数据库的版本控制系统？我不在乎特定的数据库技术。我只想知道是否存在。如果碰巧可以与MS SQL Server配合使用，那就太好了。

在Ruby on Rails中，有一个迁移的概念-一种用于更改数据库的快速脚本。

您生成一个迁移文件，该文件具有增加数据库版本的规则（例如，添加列）和具有降级版本的规则（例如，删除列）。每个迁移都有编号，并且有一个表跟踪您当前的数据库版本。

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

迁移脚本本身保存在版本控制系统中-每当您更改数据库时，都需要签入新脚本，任何开发人员都可以应用该脚本将其本地db更新到最新版本。

我有点老套，因为我使用源文件来创建数据库。实际上有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给我的指示DB多远是关闭的基线。

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

MyBatis（以前为iBatis）具有模式迁移工具，可在命令行中使用。它是用Java编写的，尽管可以与任何项目一起使用。

为了实现良好的数据库更改管理实践，我们需要确定一些关键目标。因此，MyBatis Schema迁移系统（或简称为MyBatis迁移）旨在：

• 使用任何新数据库或现有数据库
• 利用源代码管理系统（例如Subversion）
• 使并发开发人员或团队能够独立工作
• 允许冲突非常明显且易于管理
• 允许向前和向后迁移（分别演进和演进）
• 使数据库的当前状态易于访问和理解
• 尽管具有访问权限或官僚机构，也可以进行迁移
• 使用任何方法
• 鼓励良好，一致的做法

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

我强烈建议使用SQL delta。我完成功能编码后，就用它生成diff脚本，并将这些脚本检入我的源代码控制工具（Mercurial :)）

它们同时具有SQL Server和Oracle版本。

我想知道没有人提到基于Java 的开放源代码工具liquibase，它几乎适用于所有支持jdbc的数据库。与rails相比，它使用xml代替ruby来执行模式更改。尽管我不喜欢将XML用于特定领域的语言，但是xml的非常酷的优点是liquibase知道如何回滚某些操作，例如

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

所以您不需要自己处理

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

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

如果您使用的是SQL Server，将很难击败Data Dude（又名Visual Studio的数据库版本）。一旦掌握了它，就可以轻松地对数据库的源代码控制版本和生产版本进行模式比较。只需单击一下，您就可以生成差异DDL。

在MSDN上有一个指导性视频，非常有用。

我知道DBMS_METADATA和Toad，但是如果有人可以提出Oracle的Data Dude，那么生活将会非常美好。

将最初的创建表语句放在版本控制器中，然后添加alter table语句，但不要编辑文件，最好按顺序甚至是“变更集”命名更多的alter文件，因此您可以查找特定部署的所有变更。

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

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

看一下oracle包DBMS_METADATA。

特别地，以下方法特别有用：

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

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

不知道对于MSSQL是否有这么简单的东西。

我与编码并行编写了数据库发行脚本，并将发行脚本保留在SS的项目特定部分中。如果我更改了需要更改数据库的代码，那么我将同时更新发行脚本。在发布之前，我在一个干净的dev db（从生产环境明智地复制结构）上运行发布脚本，并对其进行最终测试。

我已经断断续续地做到了这一点-管理（或尝试管理）模式版本。最佳方法取决于您拥有的工具。如果您可以获得Quest Software工具“ Schema Manager”，那么您的状况将会很好。Oracle有自己的劣质工具，我也不推荐使用这种工具，也称为“ Schema Manager”（令人困惑吗？）。

如果没有自动化工具（请参阅此处有关Data Dude的其他评论），那么您将直接使用脚本和DDL文件。选择一种方法，记录下来，然后严格执行。我喜欢能够在任何给定时刻重新创建数据库的功能，因此我更喜欢对整个数据库（如果我是DBA）或开发人员模式（如果我在产品中）进行完整的DDL导出。 -开发模式）。

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

ER Studio允许您将数据库架构转换为工具，然后可以将其与实时数据库进行比较。

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

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

有一个名为Ruckusing的PHP5“数据库迁移框架”。我没有使用过它，但是示例显示了这种想法，如果您在需要时使用该语言创建数据库，则只需要跟踪源文件即可。

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

我们已经使用了MS Team System数据库版取得了很好的成功。它或多或少无缝地与TFS版本控制和Visual Studio集成在一起，使我们能够轻松管理存储的proc，视图等。解决冲突可能会很痛苦，但是一旦完成，版本历史便会完整。此后，向质量保证和生产的迁移非常简单。

可以公平地说，它是1.0版产品，而且存在不少问题。

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

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

在没有用于表更改的VCS的情况下，我一直将它们记录在Wiki中。至少那时我可以看到何时以及为何对其进行了更改。这并不是完美的，因为不是每个人都在做，而且我们有多个产品版本在使用中，但总比没有好。

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

另一个想法是打开DDL审核（在Oracle中有效）。这将创建一个表格，其中包含您所做的所有更改。如果您从上次将数据库更改更改为prod到现在的时间戳查询更改，则将按顺序列出已完成的所有操作。一些where子句可以消除零和更改，例如create table foo;。随后是drop table foo; 您可以轻松地构建一个mod脚本。为什么要将更改保留在Wiki中，这是工作的两倍。让数据库为您跟踪它们。

有两本书的建议：Ambler和Sadalage的“重构数据库”和Ambler的“敏捷数据库技术”。

有人提到了Rails迁移。我认为即使在Rails应用程序之外，它们也能很好地工作。我在SQL Server的ASP应用程序中使用了它们，而我们正在向Rails迁移。您可以将迁移脚本本身检入VCS。这是Pragmatic Dave Thomas关于这个主题的帖子。