是否有数据库结构更改的版本控制系统？
我经常遇到以下问题。
我正在对需要数据库中的新表或列的项目进行一些更改。 我做了数据库修改，并继续我的工作。 通常情况下，我会记下这些更改，以便在实时系统上进行复制。 但是，我并不总是记得我已经改变了什么，我并不总是记得把它写下来。
所以，我推动了现场系统，并得到一个大的，明显的错误，没有NewColumnX ，呃。
不pipe这种情况可能不是最佳实践，是否有数据库版本控制系统？ 我不关心具体的数据库技术。 我只想知道是否存在 如果碰巧与MS SQL Server一起工作，那么很好。
在Ruby on Rails中，有一个迁移的概念 – 一个用来更改数据库的快速脚本。
您生成一个迁移文件，该文件具有增加数据库版本（如添加列）的规则以及降级版本的规则（如删除列）。 每个迁移编号，一个表跟踪您当前的数据库版本。
要进行迁移 ，可以运行一个名为“db：migrate”的命令，查看您的版本并应用所需的脚本。 你可以用类似的方式迁移。
迁移脚本本身保存在一个版本控制系统中 – 无论何时您更改数据库时，都会检入一个新脚本，任何开发人员都可以将其应用到本地数据库中。
我有点老派，因为我使用源文件来创build数据库。 实际上有两个文件 – project-database.sql和project-updates.sql – 第一个用于模式和持久性数据，第二个用于修改。 当然，两者都受到源头控制。
当数据库发生更改时，首先更新project-database.sql中的主模式，然后将相关信息复制到project-updates.sql中，例如ALTER TABLE语句。 然后，我可以将更新应用到开发数据库，testing，迭代，直到完成。 然后，检查文件，再次testing，并应用于生产。
另外，我通常在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';
只有在重新创build数据库时， db_version才会发生变化，而db_revision告诉我数据库离基线有多远。
我可以将更新保留在自己的单独文件中，但我select将它们混合在一起，然后使用剪切和粘贴来提取相关的部分。 更多的pipe家是为了，即从$ Revision 1.1 $中删除'：'来冻结它们。
MyBatis （以前称为iBatis）有一个模式迁移 ，在命令行上使用的工具。 它是用java编写的，但可以用于任何项目。
为了实现一个好的数据库变更pipe理实践，我们需要确定几个关键目标。 因此，MyBatis架构迁移系统（或MyBatis Migrations简称）旨在：
- 使用任何新的或现有的数据库
- 利用源代码pipe理系统（如Subversion）
- 使并发开发人员或团队能够独立工作
- 允许冲突非常明显，易于pipe理
- 允许向前和向后迁移（分别进化，分别）
- 使数据库的当前状态易于访问和理解
- 尽pipe有访问权限或官僚机构，仍然启用迁移
- 使用任何方法
- 鼓励良好的，一贯的做法
Redgate有一个名为SQL Source Control的产品。 它集成了TFS，SVN，SourceGear Vault，Vault Pro，Mercurial，Perforce和Git。
我强烈build议SQL增量 。 我只是用它来生成diff脚本，当我编写我的function，并检查这些脚本到我的源代码pipe理工具（Mercurial :)）
他们有一个SQL服务器和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的Database Edition）。 一旦掌握了它，就可以轻松地在数据库的源代码控制版本和生产版本之间进行模式比较。 只需点击一下，你就可以生成你的差异DDL。
MSDN上有一个教学video ，非常有帮助。
我知道DBMS_METADATA和Toad，但是如果有人能够为Oracle提供一个Data Dude，那么生活将会非常的甜蜜。
在版本控制器中有最初的创build表语句，然后添加alter table语句，但不要编辑文件，更多的理想依次命名的alter文件，甚至是“更改集”，以便find特定部署的所有更改。
我能看到的最难的部分是跟踪依赖关系，例如，对于特定的部署表B，可能需要在表A之前更新表B.
对于Oracle，我使用Toad ，它可以将模式转储到大量离散文件（例如，每个表一个文件）。 我有一些在Perforce中pipe理这个集合的脚本，但是我认为在任何版本控制系统中都应该很容易实现。
看看oracle包DBMS_METADATA。
具体而言，以下方法特别有用：
-
DBMS_METADATA.GET_DDL -
DBMS_METADATA.SET_TRANSFORM_PARAM -
DBMS_METADATA.GET_GRANTED_DDL
一旦你熟悉它们的工作方式（可以自我解释），你可以编写一个简单的脚本来将这些方法的结果转储到可以放在源代码控制之下的文本文件中。 祝你好运！
不知道是否有这样简单的MSSQL的东西。
我编写我的数据库发行脚本与编码并行，并保持释放脚本在SS中的项目特定部分。 如果对需要更改数据库的代码进行更改，则同时更新发行脚本。 在发布之前，我在一个干净的开发数据库（从生产复制结构明智）上运行发行脚本，并对其进行最终testing。
我已经做了很多年 – pipe理（或尝试pipe理）模式版本。 最好的方法取决于你所拥有的工具。 如果您可以获得Quest Software工具“架构pipe理器”，那么您将处于良好状态。 甲骨文有自己的劣质工具，也被称为“模式pipe理器”（困惑很多？），我不build议。
如果没有一个自动化的工具（请参阅Data Dude的其他评论），那么您将直接使用脚本和DDL文件。 select一个方法，logging下来，并严格遵守。 我喜欢有能力在任何时候重新创build数据库，所以我更喜欢有一个完整的DDL导出整个数据库（如果我是DBA）或开发人员架构（如果我在产品 – 发展模式）。
所有Arround Automations公司的工具PLSQL Developer都有一个插件库，可以与Visual Source Safe一起工作。
来自networking：
版本控制插件提供了PL / SQL Developer IDE >>和任何支持Microsoft SCC接口规范的版本控制系统之间的紧密集成。 >>这包括最stream行的版本控制系统，如Microsoft Visual SourceSafe，>> Merant PVCS和MKS Source Integrity。
有一个名为Ruckusing的PHP5“数据库迁移框架”。 我没有使用它，但是例子显示了这个想法，如果你使用语言来创build数据库，那么你只需要跟踪源文件。
ER Studio允许您将数据库模式转换为工具，然后将其与实时数据库进行比较。
示例：将您的开发模式反转到ER Studio中 – 将其与生产进行比较，并列出所有差异。 它可以编写脚本，或者只是自动推送。
在ER Studio中创build了模式后，您可以保存创build脚本，也可以将其保存为专有二进制文件，并将其保存在版本控制中。 如果你想回到过去的版本的scheme，只是检查出来，推到你的数据库平台。
您可以在Visual Studio中使用Microsoft SQL Server数据工具来为数据库对象生成脚本，作为SQL Server项目的一部分。 然后，您可以使用Visual Studio中内置的源代码控制集成将脚本添加到源代码pipe理。 此外，SQL Server项目允许您使用编译器validation数据库对象，并生成部署脚本来更新现有的数据库或创build一个新的数据库。
我们已经使用MS Team System数据库版 ，取得了相当不错的成绩。 它与TFS版本控制和Visual Studio无缝地集成，允许我们轻松地pipe理存储过程，视图等。 冲突解决可能是一个痛苦，但是一旦完成，版本历史就完成了。 此后，迁移到质量保证和生产是非常简单的。
可以这么说，它是1.0版本的产品，并不是没有几个问题。
Oracle的Schema Compare是一个特别devise的工具，用于将Oracle数据库的更改迁移到另一个。 请访问下面的链接下载链接，在那里你将能够使用该软件进行全function的试用。
http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm
在没有用于表格更改的VCS时，我已经将它们logging在wiki中。 至less可以看到什么时候以及为什么改变了。 这不是完美的，因为不是每个人都在做，我们有多个产品版本在使用，但总比没有好。
两本书build议：Ambler和Sadalage的“重构数据库”和Ambler的“敏捷数据库技术”。
有人提到了Rails Migrations。 我认为他们工作得很好，甚至在Rails应用程序之外。 我使用SQL Server的ASP应用程序，我们正在移动到Rails的过程中。 您将迁移脚本自己检入到VCS中。 以下是Pragmatic Dave Thomas撰写的关于这个主题的文章。
我推荐两种方法之一。 首先，从Sybase投资PowerDesigner 。 企业版。 它可以让你devise物理数据模型，还有更多。 但它带有一个存储库，允许您检查模型。 每次新签入都可以是新版本，它可以将任何版本与任何其他版本进行比较，甚至可以比较当时数据库中的内容。 然后，它会列出每一个差异的清单，并询问哪些应该迁移…然后build立脚本来做到这一点。 这不便宜，但价格便宜两倍，投资回报期约为6个月。
另一个想法是打开DDL审计（在Oracle中工作）。 这将创build一个表，每一个你做的改变。 如果您查询最后一次移动数据库时间戳的时间戳更改，您将得到一个您已经完成的所有事情的有序列表。 几个where子句中消除零和变化如create table foo; 之后是drop table foo; 你可以轻松地build立一个mod脚本。 为什么保持在一个维基的变化，这是工作的两倍。 让数据库为你跟踪它们。
