在工作中，我们有4个人在几个不同的项目上共同努力。对于每个项目，我们每个人都有一个本地副本，然后我们进行开发，暂存和实时部署，以及我们拥有的所有分支(我们使用subversion)。我们的数据库是MySQL。

所以我的问题是，什么是管理对每个部署进行了哪些数据库修订的好方法(对于开发人员来说，它们是本地副本)。现在，每个更改都将进入一个带有名称时间戳的文本文件，并放入项目下的文件夹中。老实说，这不是很好。.我需要一个解决方案，以帮助跟踪在哪里应用了什么。

解决方案

http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx

上面的博客将我们带到了当前的数据库版本控制系统。简而言之，没有更新脚本就不会进行数据库更改，所有更新脚本都在我们的源代码控制存储库中。

我们仅管理架构更改，但我们也可能/愿意考虑在版本控制中保持数据转储的可用性。创建此类文件是使用mysqldump进行的非常简单的练习。

我们的解决方案与博客中提供的解决方案的主要不同之处在于：它不是自动化的。我们必须手动应用数据库更新等。尽管这可能会花费一些时间，但它推迟了全自动系统所需的一些工作。但是，我们实现了自动化的一件事是该软件中的数据库版本跟踪：这非常简单，它可以确保我们的软件知道正在运行的数据库，并且仅在知道要使用的模式时才运行。

解决方案中最难的部分是如何将分支中的更新合并到主干中。我们花了一些时间来开发工作流，以解决两个开发人员试图同时合并分支和数据库更新的可能性以及如何处理它。我们最终决定将文件锁定在版本控制中(我们所讨论的文件实际上是一个将软件版本映射到db版本的表，这有助于我们的手动管理策略)，就像我们在线程的关键部分，以及获得锁是关于行李箱的更新。完成后，其他开发人员将能够锁定，他们有责任对自己的脚本进行必要的更改，以确保避免预期的版本冲突和其他不良后果。

我们将所有数据库脚本(数据和架构/ ddl)保留在版本控制中。我们还保留更改的中央目录。当开发人员更改架构/ DDL文件或者添加以某种方式更改数据的脚本时，这些文件将与SVN提交号一起添加到目录中。

我们在内部汇集了一个小型实用程序，它可以通过从目录中每个修订中获取内容并将其应用来读取目录更改并基于目录的内容构建大型更新脚本。这个概念与DBDeploy工具非常相似，我相信它最初来自Thoughtworks，因此我们可以使用它。至少它将为我们提供一个良好的起点，从那时起，我们可以定制更直接适合我们需要的解决方案。

祝你好运！

如果数据库很好地映射到一组数据访问对象，请考虑使用"迁移"。想法是将数据模型存储为应用程序代码，并带有在每个数据库版本中前进和后退的步骤。

我相信Rails首先做到了。

Java至少有一个项目。

这是一个.NET迁移库。

要更改版本，我们可以运行一个简单的脚本，逐步浏览所有向上或者向下的版本，以获取所需的版本。这样做的好处是，我们可以将迁移和应用程序代码检查到同一个源存储库中，这一切都集中在一个地方。

也许其他人可以建议其他迁移库。

干杯。

编辑：另请参阅https://stackoverflow.com/questions/313/net-migrations-engine和.NET数据库迁移工具综述(来自以上文章)。