在工作中，我们有4个人在几个不同的项目上一起工作。对于每个项目，我们都有一个本地副本，然后进行开发，暂存和实时部署，以及我们拥有的任何分支（我们使用Subversion）。我们的数据库是MySQL。如何在具有分支机构的中型项目上管理数据库修订版本？
所以我的问题是，什么是管理对每个部署（以及开发人员本地副本）对数据库进行哪些修订的好方法。现在，每次更改都会进入一个文本文件，该文件在名称中加上时间戳，并放入项目下的文件夹中。老实说，这不是很好。我需要一个解决方案来帮助跟踪哪些地方应用了什么。
如果您的数据库很好地映射到一组数据访问对象，请考虑使用“迁移”。这个想法是将你的数据模型作为应用程序代码存储起来，并在每个数据库版本中前后移动。我相信Rails did it first。
Java有at least one project。
而且这里有一个.NET migration library。
要更改版本，你运行一个简单的脚本，通过所有的向上或向下版本的步骤让你你想要的版本。它的美妙之处在于，您可以将您的迁移与您的应用程序代码一起检入同一个源代码库 - 全部集中在一个地方。
也许别人可以建议其他迁移库。
干杯。
编辑：参见https://stackoverflow.com/questions/313/net-migrations-engine和.NET database migration tool roundup（从上面交）。
http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx
上述博客给我们带来了我们现在的数据库版本控制系统。简而言之，没有更新脚本就不会更改数据库，并且所有更新脚本都位于我们的源代码管理存储库中。
我们只管理模式更改，但您也可以/愿意考虑在版本控制中保留数据的转储;使用mysqldump创建这样的文件是非常简单的练习。
我们的解决方案与博客中呈现的解决方案有一个不同之处：它不是自动化的。我们必须手动应用数据库更新等。虽然这可能会稍微耗时，但它推迟了全自动化系统所需的部分工作量。然而，我们做了一个自动化的事情，就是软件中的数据库版本跟踪：这非常简单，它确保我们的软件知道它正在运行的数据库，并且只有在知道它正在使用的模式时才会运行。
我们解决方案中最难的部分是如何将我们分支的更新合并到我们的主干中。我们花了一些时间来开发一个工作流，以解决两个开发人员尝试将分支与数据库更新同时合并以及如何处理它的可能性。我们最终决定在版本控制中锁定一个文件（我们讨论的文件实际上是一个将软件版本映射到db版本的表格，这有助于我们的手动管理策略），就像您对线程的关键部分以及开发人员锁继续关于他们的干线更新。完成后，其他开发人员将能够锁定，他们有责任对其脚本进行必要的更改，以确保避免预期的版本冲突和其他不良Juju。
我们将所有的数据库脚本（data和schema/ddl）保存在版本控制中。我们也保留一个中央目录的变化。当开发人员更改模式/ DDL文件或添加以某种方式更改数据的脚本时，这些文件将与SVN提交编号一起添加到目录中。
我们已经组建了一个内部小公共事业公司，它通过抓取目录中每个修订版的内容并应用它们来读取目录更改，并根据目录内容构建一个较大的更新脚本。这个概念非常类似于DBDeploy工具，我相信它最初来自Thoughtworks，所以您可能可以使用它。它至少会为您提供一个开始的好地方，从这个角度您可以定制更适合您需求的解决方案。
祝你好运！
我已阅读本，和诚实，我不喜欢这个主意。我认为需要构建一个完整的系统才能真正为多个部署提供支持。 – Greg 2008-10-01 02:57:39
在您所描述的内容中增加了一些内容：确实需要构建一些基础结构工具以获得该解决方案，但并非所有工具都是必需的（我们选择不允许该软件“自我更新”），并且这是一个强大的解决方案，初期的努力很快就会收回成效。 – antik 2008-10-01 03:10:46