我们维护由ER工具(PowerAMC)生成的DDL(有时是DML)脚本。

我们有一个shell脚本工作台，它重命名以主干分支上的数字开头的脚本。 提交每个脚本并标记bugzilla编号。

这些脚本在需要时与应用程序代码合并到发布分支中。

我们有一个记录脚本及其状态的表。 在部署工具的每次安装中，每个脚本都按顺序执行，并记录在此表中。

我们在源代码控制下有创建/修改脚本。至于数据库本身，当您有数百个表并且每分钟处理大量数据时，对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来，备份仍然是控制数据的最佳方式。

是的，我们的源代码控制我们的sql脚本也与subversion。这是一个很好的实践，您可以在需要时使用默认数据重新创建模式。

我所见过的最佳实践是创建一个构建脚本，在登台服务器上废弃并重新构建数据库。每次迭代都有一个用于数据库更改的文件夹，所有更改都用“Drop…创建“”。这样，您可以通过将构建指向您想要版本的文件夹，随时回滚到较早的版本。

我相信这是用NaNt/CruiseControl完成的。

我使用SchemaBank来版本控制我所有的数据库模式更改:

从第一天开始，我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时，我从它生成更改(SQL)脚本并应用到db。在Schemabank中，它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习，这样当我需要的时候，我就可以随时追溯。

我们的团队规则是，在没有存储设计工作之前，永远不要直接接触db服务器。但它发生了，有人可能会被诱惑打破规则，为了方便。我们将再次将模式转储导入到模式银行中，并让它执行diff，如果发现不一致，则对某人进行攻击。虽然我们可以从它生成alter脚本，使我们的db和模式设计同步，但我们讨厌这样做。

顺便说一下，它们还允许我们在版本控制树中创建分支，这样我就可以维护一个用于登台，一个用于生产。还有一个用于编码沙盒。

一个非常整洁的基于web的模式设计工具，带有版本控制和变更管理。

我对创建脚本进行了版本控制，并在其中使用了svn版本标记。然后，每当我得到一个将要使用的版本时，我就在dbpatches/目录中创建一个脚本，命名为要上卷到的版本。该脚本的任务是在不破坏数据的情况下修改当前数据库。例如，Dbpatches /可能有名为201、220和240的文件。如果数据库当前处于201级别，则应用补丁220，然后再应用补丁240。

DROP TABLE IF EXISTS `meta`;
CREATE TABLE `meta` (
  `property` varchar(255),
  `value` varchar(255),
  PRIMARY KEY (`property`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO `meta` VALUES ('version', '$Rev: 240 $');

在考虑一个好的补丁之前，不要忘记测试你的代码。购者自慎!