跟踪和/或自动执行数据库架构更改的最佳方法是什么？我们的团队使用Subversion进行版本控制，并且我们已经能够以这种方式自动执行一些任务(将构建推送到登台服务器，将经过测试的代码部署到生产服务器)，但是我们仍在手动进行数据库更新。我想找到或创建一个解决方案，使我们能够在具有不同环境的服务器之间高效地工作，同时继续使用Subversion作为后端，通过该后端代码和数据库更新被推送到各种服务器。
许多流行的软件包都包括自动更新脚本，该脚本可检测数据库版本并应用必要的更改。这是否是在更大范围内(跨多个项目，有时跨多种环境和语言)执行此操作的最佳方法？如果是这样，是否有任何现有代码可以简化流程，或者最好只是推出我们自己的解决方案？之前有没有人实现过类似的东西并将其集成到Subversion提交后钩子中，还是一个坏主意？
虽然支持多个平台的解决方案是更可取的，但是我们绝大部分需要在该平台上支持Linux / Apache / MySQL / PHP堆栈。
在Rails世界中，存在迁移的概念，即脚本，其中对数据库的更改是使用Ruby而不是特定于数据库的SQL风格进行的。您的Ruby迁移代码最终将转换为特定于您当前数据库的DDL。这使得切换数据库平台非常容易。
对于您对数据库所做的每一次更改，您都要编写一个新的迁移。迁移通常有两种方法：应用更改的"上"方法和撤消更改的"下"方法。单个命令可以使数据库更新，也可以用于将数据库带到架构的特定版本。在Rails中，迁移与项目其他代码一样，都保存在项目目录中自己的目录中，并被检入版本控制中。
该Oracle Rails迁移指南很好地介绍了迁移。
使用其他语言的开发人员已经研究了迁移并实现了自己的特定于语言的版本。我知道Ruckusing是一个以Rails的迁移为模型的PHP迁移系统。这可能是您要寻找的。
我们使用类似于bcwoord的方法来保持数据库模式在5个不同的安装(生产，暂存和一些开发安装)之间同步，并在版本控制中进行备份，并且效果很好。我会详细说明：
为了同步数据库结构，我们有一个脚本update.php和许多编号为1.sql，2.sql，3.sql等的文件。该脚本使用一个额外的表来存储数据库的当前版本号。数据库。 N.sql文件是手工制作的，以从数据库的版本(N-1)升级到版本N。
它们可用于添加表，添加列，将数据从旧的格式迁移到新的列格式，然后删除列，插入"主"数据行(例如用户类型)等。基本上，它可以执行任何操作并使用适当的数据迁移脚本，您将永远不会丢失数据。
更新脚本的工作方式如下：
-
Connect to the database.
-
Make a backup of the current database (because stuff will go wrong) [mysqldump].
-
Create bookkeeping table (called _meta) if it doesn't exist.
-
Read current VERSION from _meta table. Assume 0 if not found.
-
For all .sql files numbered higher than VERSION, execute them in order
-
If one of the files produced an error: roll back to the backup
-
Otherwise, update the version in the bookkeeping table to the highest .sql file executed.
一切都进入源代码控制，并且每个安装都有一个脚本，可通过一次脚本执行将脚本更新到最新版本(使用正确的数据库密码调用update.php等)。我们通过自动调用数据库更新脚本的脚本来SVN更新登台和生产环境，因此代码更新随附必需的数据库更新。
我们还可以使用相同的脚本从头开始创建整个数据库。我们只是删除并重新创建数据库，然后运行将完全重新填充数据库的脚本。我们还可以使用脚本填充空数据库以进行自动测试。
设置该系统仅花费了几个小时，从概念上讲它很简单，每个人都可以使用版本编号方案，并且它具有前进和发展数据库设计的能力，而无需沟通或手动执行修改，这是无价的。在所有数据库上。
但是当从phpMyAdmin粘贴查询时要当心！这些生成的查询通常包含数据库名称，您肯定不希望使用该数据库名称，因为它会破坏脚本！如果系统上的数据库未称为mydb，则CREATE TABLE mydb。newtable(...)之类的操作将失败。我们创建了一个注释前的SVN钩子，该钩子将禁止包含mydb字符串的.sql文件，这是有人未经适当检查就从phpMyAdmin复制/粘贴的肯定标志。
我的团队编写了所有数据库更改的脚本，并将这些脚本以及应用程序的每个版本提交给SVN。这允许增量更改数据库，而不会丢失任何数据。
要从一个发行版过渡到另一个发行版，您只需要运行一组更改脚本，并且数据库是最新的，您仍然可以获得所有数据。它可能不是最简单的方法，但绝对有效。
如果您仍在寻找解决方案：我们建议使用一种名为neXtep designer的工具。这是一个数据库开发环境，您可以使用该环境将整个数据库置于版本控制之下。您在版本控制的存储库上工作，可以跟踪每个更改。
当需要发布更新时，您可以提交组件，产品将自动从先前版本生成SQL升级脚本。当然，您可以从任意两个版本生成此SQL。
然后，您有很多选择：您可以将这些脚本与应用程序代码一起放入SVN中，以便通过现有机制进行部署。另一个选择是使用neXtep的传递机制：脚本以"传递包"(SQL脚本+ XML描述符)的形式导出，安装程序可以理解此包并将其部署到目标服务器，同时确保结构一致性，依赖性检查，注册已安装的版本等。
该产品是GPL，基于Eclipse，因此可以在Linux，Mac和Windows上运行。目前它还支持Oracle，Mysql和Postgresql(正在支持DB2)。查看Wiki，您将在其中找到更多详细信息：
http://www.nextep-softwares.com/wiki
真正的问题是，开发人员可以轻松地将自己的本地更改编写到源代码管理中，以便与团队共享。我已经面对这个问题很多年了，并且受到Visual Studio for Database专业人士功能的启发。如果您想要具有相同功能的开源工具，请尝试以下操作：http://dbsourcetools.codeplex.com/
玩得开心，
-内森。
将模式转储到文件中，并将其添加到源代码管理中。然后一个简单的差异将告诉您发生了什么变化。
Scott Ambler撰写了大量有关数据库重构的文章(并与人合着)，其思想是您应实质上将TDD原理和实践应用于维护架构。您为数据库设置了一系列结构和种子数据单元测试。然后，在您进行任何更改之前，您都要修改/编写测试以反映该更改。
我们已经这样做了一段时间了，而且似乎可行。我们编写了在单元测试套件中生成基本列名和数据类型检查的代码。我们可以随时重新运行这些测试，以验证SVN检出中的数据库是否与应用程序实际运行的实时数据库匹配。
事实证明，开发人员有时还会调整其沙箱数据库，而忽略了更新SVN中的架构文件。然后，代码取决于尚未签入的数据库更改。这种错误很难确定，但是测试套件会立即将其修复。如果您将其内置到较大的持续集成计划中，则特别好。
K. Scott Allen撰写了一篇有关架构版本的不错的文章，其中使用了本文其他答案中引用的增量更新脚本/迁移概念；参见http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx。
这是一项低技术，可能会有更好的解决方案，但是您可以将架构存储在可以运行以创建数据库的SQL脚本中。我认为您可以执行命令来生成此脚本，但是不幸的是我不知道该命令。
然后，将脚本及其上的代码提交到源代码管理中。当您需要与代码一起更改模式时，可以将脚本与需要更改的模式的代码一起检入。然后，脚本上的差异将指示架构更改上的差异。
使用此脚本，您可以将其与DBUnit或某种构建脚本集成，因此看来它可以与您已经自动化的流程配合使用。
我在Visual Studio中将以下数据库项目结构用于多个项目，并且效果很好：
数据库
Change Scripts
0.PreDeploy.sql
1.SchemaChanges.sql
2.DataChanges.sql
3.Permissions.sql
创建脚本
Sprocs
Functions
Views
然后，我们的构建系统通过按以下顺序执行脚本，将数据库从一个版本更新到另一个版本：
1.PreDeploy.sql
2.SchemaChanges.sql
Contents of Create Scripts folder
2.DataChanges.sql
3.Permissions.sql
每个开发人员通过将他们的代码附加到每个文件的末尾来检查其更改是否存在特定的错误/功能。完成主要版本并在源代码管理中分支后，更改脚本文件夹中的.sql文件的内容将被删除。
我们使用一个非常简单但有效的解决方案。
对于新安装，我们在存储库中有一个metadata.sql文件，其中包含所有数据库模式，然后在构建过程中，我们使用此文件来生成数据库。
对于更新，我们将更新添加到经过硬编码的软件中。我们对它进行硬编码，因为我们不喜欢在问题真正成为问题之前就解决问题，而且到目前为止，这种事情尚未证明是问题。
因此，在我们的软件中，我们有以下内容：
RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');
此代码将检查数据库是否为版本1(存储在自动创建的表中)，如果版本已过时，则执行命令。
为了更新存储库中的metadata.sql，我们在本地运行此升级，然后提取完整的数据库元数据。
经常发生的唯一事情就是忘记提交metadata.sql，但这不是主要问题，因为它易于在构建过程中进行测试，并且唯一可能发生的事情是使用进行新安装一个过时的数据库，并在首次使用时对其进行了升级。
同样，我们不支持降级，但是这是设计使然，如果更新中出现问题，我们将还原先前的版本并修复更新，然后再尝试。
如果您使用的是C＃，请查看Subsonic，这是一个非常有用的ORM工具，但它也会生成sql脚本来重新创建您的方案和/或数据。然后可以将这些脚本放入源代码管理中。
http://subsonicproject.com/
我创建以构建版本命名的文件夹，然后在其中放置升级和降级脚本。例如，您可能具有以下文件夹：1.0.0、1.0.1和1.0.2。每个脚本都包含一个脚本，该脚本使您可以在两个版本之间升级或降级数据库。
如果客户或客户致电给您有关1.0.1版本的问题，而您正在使用1.0.2，则将数据库恢复到他的版本将不会有问题。
在数据库中，创建一个名为" schema"的表，在其中放置数据库的当前版本。然后，编写一个可以为您升级或降级数据库的程序很容易。
就像乔伊(Joey)所说的那样，如果您在Rails世界中，请使用Migrations。 :)
我建议使用Ant(跨平台)作为"脚本"端(因为它实际上可以通过jdbc与那里的任何数据库对话)和Subversion作为源存储库。
在进行更改之前，Ant会允许您将数据库"备份"到本地文件。
1.通过Ant将现有的数据库架构备份到文件
2.通过Ant对Subversion存储库进行版本控制
3.通过Ant将新的sql语句发送到db
尝试db-deploy-主要是Java工具，但也可以与php一起使用。
-
http://dbdeploy.com/
-
http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html
Toad for MySQL具有称为架构比较的功能，该功能可让您同步2个数据库。到目前为止，这是我使用过的最好的工具。
我喜欢Yii处理数据库迁移的方式。迁移基本上是实现CDbMigration的PHP脚本。 CDbMigration定义了一个包含迁移逻辑的up方法。也可以实现down方法来支持迁移的逆转。或者，可以使用safeUp或safeDown来确保在事务上下文中完成迁移。
Yii的命令行工具yiic包含对创建和执行迁移的支持。可以逐个或批量应用或撤消迁移。创建迁移会为实现CDbMigration的PHP类的代码生成代码，该代码基于时间戳和用户指定的迁移名称进行唯一命名。先前已应用于数据库的所有迁移都存储在迁移表中。
有关更多信息，请参见手册中的"数据库迁移"文章。
对于我当前的PHP项目，我们使用Rails迁移的概念，并且有一个migrations目录，其中保留文件名为" migration_XX.sql"的文件，其中XX是迁移的编号。当前，这些文件是在进行更新时手动创建的，但是可以轻松修改它们的创建。
然后，我们有一个名为" Migration_watcher"的脚本，正如在pre-alpha中一样，该脚本当前在每次页面加载时运行，并检查是否存在一个新的migration_XX.sql文件，其中XX大于当前迁移版本。如果这样的话，它将对数据库和所有数据库最大运行所有的migration_XX.sql文件！模式更改是自动的。
如果您需要还原系统的功能，则需要进行大量的调整，但这很简单，到目前为止，对于我们规模较小的团队来说，它一直运转良好。
恕我直言，迁移确实有一个巨大的问题：
从一个版本升级到另一个版本可以很好地工作，但是如果您有数百个表并且有很长的更改历史记录(如我们一样)，那么全新安装给定版本可能会花费很多时间。
从基线运行到当前版本(用于数百个客户数据库)的整个增量增量历史可能会花费很长时间。
有一个命令行mysql-diff工具可以比较数据库模式，其中模式可以是实时数据库或磁盘上的SQL脚本。它适合大多数架构迁移任务。
