如何维护数据库结构的修订控制？

Question

跟踪项目数据库结构更改的最简单方法是什么？

当我改变数据库的某些内容时（例如，添加新表，向现有表添加新字段，添加索引等），我希望将其传播到团队的其他成员，最终生成服务器，用最小的麻烦和努力。

目前，解决方案非常薄弱，依赖于人们记住要做的事情，这是一个等待发生的事故。

其他所有内容均使用标准版本控制软件（在我们的案例中为Perforce）进行管理。

我们使用MySQL，所以理解这些的工具会有所帮助，尽管我也有兴趣了解其他地方如何处理这个问题，无论数据库引擎如何。

Answer 1

您可以转储架构并提交它 - 而RCS将负责版本之间的更改。

Answer 2

你可以从Red-Gate获得一个类似Sql Compare的工具，它允许你指向两个数据库，它会让你知道什么是不同的，并将为你构建更改脚本。

如果您使用的是.NET（Visual Studio），则可以创建一个数据库项目并将其检入源代码管理中。

Answer 3

我认为这已经经过了很多讨论。无论如何我真的很喜欢Rails处理这个问题。它的代码有三个：

1. 版本号
2. 应用更改的方式（更新版本表）
3. 回滚更改的方式（将版本表上的版本设置为上一个）

因此，每次创建变更集时，都会创建此代码文件，以便在执行时回滚或升级数据库模式。

这是代码，您可以在任何修订控制系统中提交。您只提交第一个转储，然后提交脚本。

这种方法的好处在于您可以轻松地将数据库更改分发给客户，而使用标准只是转储模式并更新它生成升级/回滚脚本的方法是一件麻烦事情

Answer 4

在我的公司中，鼓励每个开发人员将所有数据库结构更改保存到包含模块修订号的文件夹中的脚本文件中。这些脚本保存在svn存储库中。

当应用程序启动时，db升级代码会比较当前的db版本和代码版本，如果代码更新 - 查看脚本文件夹并自动应用所有数据库更改。

这样每个应用程序实例（在生产或开发人员机器上）总是将db升级到他们的代码版本，并且它运行良好。

当然，如果我们找到合适的工具，可以添加一些自动化。

Answer 5

糟糕的版本控制：

每个对象（表，视图等）的单独文件

更改表时，您希望将CREATE TABLE与CREATE TABLE区分开来。源代码历史记录用于传达故事。你不能做一个有意义的CREATE TABLE和ALTER TABLE

的差异

尝试更改文件，然后将它们提交给源代码控制，然后将它们提交到SQL数据库。大多数工具都不能很好地支持这一点，因为在测试之前不应该提交源代码控制，如果不将代码放入SQL中就无法进行测试。因此在实践中，您尝试使用SQL Redgate将文件与SQL数据库进行比较。如果做不到这一点，你就会采取严厉的政策，将数据库中的所有内容都删除，并将其替换为使其成为源代码控制的内容。

更改脚本通常是单独使用的，但是存在应用程序，例如wordpress，您需要将架构从1.0移动到1.1,1.1到1.5等等。每个应该受源代码控制并且如此修改（即你发现脚本中的bug会将你从1.0移动到1.1，你创建了该脚本的新版本，而不是另一个脚本）