在工作中，我们有4个人在几个不同的项目上一起工作。对于每个项目，我们每个项目都有一个本地副本，然后是开发，暂存和实时部署，以及我们拥有的任何分支（我们使用subversion）。我们的数据库是MySQL。
所以我的问题是，管理每个部署（以及开发人员本地副本）对数据库进行哪些修订的好方法是什么。现在，每个更改都会进入一个文本文件，该文件在名称中加上时间戳并放入项目下的文件夹中。说实话，这并不是很好。我需要一个能够帮助跟踪所应用内容的解决方案。
在工作中，我们有4个人在几个不同的项目上一起工作。对于每个项目，我们每个项目都有一个本地副本，然后是开发，暂存和实时部署，以及我们拥有的任何分支（我们使用subversion）。我们的数据库是MySQL。
所以我的问题是，管理每个部署（以及开发人员本地副本）对数据库进行哪些修订的好方法是什么。现在，每个更改都会进入一个文本文件，该文件在名称中加上时间戳并放入项目下的文件夹中。说实话，这并不是很好。我需要一个能够帮助跟踪所应用内容的解决方案。
如果您的数据库很好地映射到一组数据访问对象，请考虑使用“迁移”。我们的想法是将您的数据模型存储为应用程序代码，并在每个数据库版本中前进和后退。
我相信 Rails首先做到了。
Java有 至少一个项目。
这是一个 .NET迁移库。
要更改版本，请运行一个简单的脚本，该脚本会逐步执行所有向上或向下版本，以使您获得所需的版本。它的美妙之处在于，您将迁移检查到与应用程序代码相同的源存储库中 - 它们都在一个地方。
也许其他人可以建议其他迁移库。
干杯。
编辑：另见 https://stackoverflow.com/questions/313/net-migrations-engine 和 .NET数据库迁移工具综述 （来自上面的帖子）。
如果您的数据库很好地映射到一组数据访问对象，请考虑使用“迁移”。我们的想法是将您的数据模型存储为应用程序代码，并在每个数据库版本中前进和后退。
我相信 Rails首先做到了。
Java有 至少一个项目。
这是一个 .NET迁移库。
要更改版本，请运行一个简单的脚本，该脚本会逐步执行所有向上或向下版本，以使您获得所需的版本。它的美妙之处在于，您将迁移检查到与应用程序代码相同的源存储库中 - 它们都在一个地方。
也许其他人可以建议其他迁移库。
干杯。
编辑：另见 https://stackoverflow.com/questions/313/net-migrations-engine 和 .NET数据库迁移工具综述 （来自上面的帖子）。
http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx
以上博客将我们带到了我们当前的数据库版本控制系统。简而言之，没有更新脚本就不会进行数据库更改，并且所有更新脚本都在我们的源代码控制存储库中。
我们只管理架构更改，但您也可能/愿意考虑在版本控制中保留数据转储;使用mysqldump创建这样的文件是一项非常简单的练习。
我们的解决方案与博客中以一种关键方式呈现的解决方案不同：它不是自动化的。我们必须手动应用数据库更新等。虽然这可能会耗费一些时间，但它推迟了全自动系统所需的一些工作量。然而，我们自动化的一件事是软件中的db版本跟踪：这非常简单，它确保我们的软件知道它正在运行的数据库，并且只有在知道它正在使用的架构时才会运行。
我们解决方案中最难的部分是如何将我们分支机构的更新合并到我们的主干中。我们花了一些时间来开发工作流来解决两个开发人员同时尝试将分支与数据库更新合并以及如何处理它的可能性。我们最终确定了在版本控制中锁定文件（我们所讨论的文件实际上是一个表格映射软件版本到db版本，这有助于我们的手动管理策略），就像你的线程的关键部分和开发人员一样锁是关于他们更新主干的。完成后，其他开发人员将能够锁定，并且他们有责任对其脚本进行必要的更改，以确保避免预期的版本冲突和其他不良的juju。
我们将所有数据库脚本（数据和架构/ ddl）保存在版本控制中。我们还保留了变更的中央目录。当开发人员更改架构/ DDL文件或添加以某种方式更改数据的脚本时，这些文件将与SVN提交编号一起添加到目录中。
我们在内部组建了一个小实用程序，它通过从目录中的每个修订中获取内容并应用它们来读取目录更改并根据目录的内容构建大型更新脚本。这个概念非常相似 DBDeploy 工具，我相信最初来自 ThoughtWorks的，所以你可以利用它。它至少可以为您提供一个良好的起点，从这一点上您可以定制更直接适合您需求的解决方案。
祝你好运！