跟踪数据库模式更改的机制[关闭]

Question

跟踪和/或自动化数据库架构更改的最佳方法是什么？我们的团队使用 Subversion 进行版本控制，并且我们已经能够通过这种方式自动执行一些任务（将构建推送到临时服务器，将测试代码部署到生产服务器），但我们仍然手动执行数据库更新。我想找到或创建一个解决方案，使我们能够跨不同环境的服务器高效工作，同时继续使用 Subversion 作为后端，通过该后端将代码和数据库更新推送到各种服务器。

许多流行的软件包都包含自动更新脚本，可以检测数据库版本并应用必要的更改。即使在更大范围内（跨多个项目，有时跨多个环境和语言），这是否是最好的方法？如果是这样，是否有任何现有代码可以简化流程，或者最好只是推出我们自己的解决方案？有没有人之前实现过类似的东西并将其集成到 Subversion 提交后挂钩中，或者这是一个坏主意？

虽然支持多个平台的解决方案会更好，但我们绝对需要支持 Linux/Apache/MySQL/PHP 堆栈，因为我们的大部分工作都在该平台上。

Answer 1

在 Rails 世界中，存在迁移的概念，即使用 Ruby 脚本对数据库进行更改，而不是使用特定于数据库的 SQL 风格。您的 Ruby 迁移代码最终会被转换为特定于当前数据库的 DDL；这使得切换数据库平台变得非常容易。

对于对数据库所做的每一项更改，您都需要编写新的迁移。迁移通常有两种方法：应用更改的“向上”方法和撤消更改的“向下”方法。单个命令可使数据库保持最新状态，也可用于使数据库达到特定版本的架构。在 Rails 中，迁移保存在项目目录中自己的目录中，并像任何其他项目代码一样被签入版本控制。

Oracle Rails 迁移指南 很好地涵盖了迁移。

使用其他语言的开发人员已经研究了迁移并实现了自己的特定于语言的版本。我知道 拉克使用, ，一个以 Rails 迁移为模型的 PHP 迁移系统；这可能就是您正在寻找的。

Answer 2

我们使用类似于 bcwoord 的东西来保持我们的数据库模式在 5 个不同的安装（生产、登台和一些开发安装）之间同步，并在版本控制中进行备份，并且它运行得很好。我会详细说明一下：

---

为了同步数据库结构，我们有一个脚本 update.php 和许多编号为 1.sql、2.sql、3.sql 等的文件。该脚本使用一张额外的表来存储数据库的当前版本号。N.sql 文件是手工制作的，用于从数据库版本 (N-1) 到版本 N。

它们可用于添加表、添加列、将数据从旧的列格式迁移到新的列格式，然后删除列、插入“主”数据行（例如用户类型）等。基本上，它可以做任何事情，并且使用正确的数据迁移脚本，您将永远不会丢失数据。

更新脚本的工作原理如下：

• 连接到数据库。
• 备份当前数据库（因为东西 将要 出错）[mysqldump]。
• 如果簿记表（称为 _meta）不存在，则创建它。
• 从 _meta 表读取当前版本。如果没有找到则假设为 0。
• 对于编号高于VERSION的所有.sql文件，按顺序执行
• 如果其中一个文件产生错误：回滚到备份
• 否则，将簿记表中的版本更新为执行的最高.sql 文件。

一切都进入源代码控制，并且每个安装都有一个脚本，可以通过单个脚本执行更新到最新版本（使用正确的数据库密码等调用 update.php ）。我们SVN通过自动调用数据库更新脚本的脚本来更新暂存和生产环境，因此代码更新伴随着必要的数据库更新。

我们还可以使用相同的脚本从头开始重新创建整个数据库；我们只需删除并重新创建数据库，然后运行脚本即可完全重新填充数据库。我们还可以使用脚本填充空数据库以进行自动化测试。

---

设置这个系统只花了几个小时，它在概念上很简单，每个人都得到了版本编号方案，并且它具有向前推进和发展数据库设计的能力，而无需沟通或手动执行修改，这是非常宝贵的在所有数据库上。

不过，粘贴来自 phpMyAdmin 的查询时要小心！ 这些生成的查询通常包含数据库名称，您绝对不想要它，因为它会破坏您的脚本！类似创建表之类的东西 mydb.newtable如果系统上的数据库不名为 mydb，(...) 将失败。我们创建了一个预注释 SVN 挂钩，它将禁止包含以下内容的 .sql 文件 mydb 字符串，这是某人未经适当检查就从 phpMyAdmin 复制/粘贴的明确标志。

Answer 3

我的团队编写了所有数据库更改的脚本，并将这些脚本与应用程序的每个版本一起提交到 SVN。这允许对数据库进行增量更改，而不会丢失任何数据。

要从一个版本转到下一个版本，您只需运行一组更改脚本，并且您的数据库是最新的，并且您仍然可以获得所有数据。这可能不是最简单的方法，但绝对有效。

Answer 4

这里的问题实际上是让开发人员可以轻松地将自己的本地更改编写到源代码管理中以便与团队共享。我多年来一直面临这个问题，并受到 Visual Studio for Database 专业人员的功能的启发。如果您想要具有相同功能的开源工具，请尝试以下操作： http://dbsourcetools.codeplex.com/ 玩得开心， - 内森。

Answer 5

如果您仍在寻找解决方案：我们提出了一个名为 neXtep 设计器的工具。它是一个数据库开发环境，您可以使用它将整个数据库置于版本控制之下。您在版本控制的存储库上工作，可以跟踪每个更改。

当您需要发布更新时，您可以提交您的组件，产品将自动生成以前版本的 SQL 升级脚本。当然，您可以从任意 2 个版本生成此 SQL。

那么你有很多选择：您可以将这些脚本与您的应用程序代码一起放入 SVN 中，以便通过您现有的机制进行部署。另一种选择是使用 neXtep 的传递机制：脚本以所谓的“交付包”（SQL 脚本 + XML 描述符）的形式导出，安装程序可以理解该包并将其部署到目标服务器，同时确保结构一致性、依赖性检查、注册安装版本等。

该产品是 GPL，基于 Eclipse，因此可以在 Linux、Mac 和 Windows 上运行。目前它还支持 Oracle、Mysql 和 Postgresql（DB2 支持即将推出）。查看 wiki，您可以找到更详细的信息：http://www.nextep-softwares.com/wiki

Answer 6

将架构转储到文件中并将其添加到源代码管理中。然后一个简单的差异将告诉你发生了什么变化。

Answer 7

斯科特·安布勒 (Scott Ambler) 撰写了一系列精彩的文章（并与人合着了 书）关于数据库重构，其理念是您应该本质上应用 TDD 原则和实践来维护您的模式。您为数据库设置了一系列结构和种子数据单元测试。然后，在更改任何内容之前，您修改/编写测试以反映该更改。

我们这样做已经有一段时间了，而且似乎很有效。我们编写了代码来在单元测试套件中生成基本的列名称和数据类型检查。我们可以随时重新运行这些测试，以验证 SVN 签出中的数据库是否与应用程序实际运行的实时数据库匹配。

事实证明，开发人员有时也会调整他们的沙箱数据库，而忽略更新 SVN 中的架构文件。然后，代码取决于尚未签入的数据库更改。这种错误可能非常难以确定，但测试套件会立即发现它。如果您将其构建到更大的持续集成计划中，这会特别好。

Answer 8

K.Scott Allen 有一篇关于模式版本控制的不错的文章，其中使用了此处其他答案中引用的增量更新脚本/迁移概念；看 http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.

Answer 9

它的技术含量较低，可能有更好的解决方案，但您可以将架构存储在 SQL 脚本中，该脚本可以运行来创建数据库。我认为您可以执行命令来生成此脚本，但不幸的是我不知道该命令。

然后，将脚本及其上的代码提交到源代码管理中。当您需要更改架构和代码时，可以将脚本与需要更改架构的代码一起检入。然后，脚本上的差异将指示架构更改上的差异。

使用此脚本，您可以将其与 DBUnit 或某种构建脚本集成，因此它似乎可以适合您已经自动化的流程。

Answer 10

如果您使用 C#，请查看 Subsonic，这是一个非常有用的 ORM 工具，而且还可以生成 sql 脚本来重新创建您的方案和/或数据。然后可以将这些脚本放入源代码管理中。

http://subsonicproject.com/

Answer 11

我在 Visual Studio 中的几个项目中使用了以下数据库项目结构，并且效果很好：

数据库

更改脚本

0.预部署.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.权限.sql

创建脚本

存储过程

功能

意见

然后，我们的构建系统通过按以下顺序执行脚本将数据库从一个版本更新到下一个版本：

1.预部署.sql

2.SchemaChanges.sql

创建脚本文件夹的内容

2.DataChanges.sql

3.权限.sql

每个开发人员通过将代码附加到每个文件的末尾来检查对特定错误/功能的更改。主要版本完成并在源代码管理中分支后，更改脚本文件夹中的 .sql 文件的内容将被删除。

Answer 12

我们使用一个非常简单但有效的解决方案。

对于新安装，我们在存储库中有一个metadata.sql 文件，其中包含所有数据库模式，然后在构建过程中我们使用该文件来生成数据库。

对于更新，我们在软件硬编码中添加更新。我们将其硬编码，因为我们不喜欢在问题真正成为问题之前解决问题，而且到目前为止这种事情还没有被证明是一个问题。

所以在我们的软件中我们有这样的东西：

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

此代码将检查数据库是否为版本 1（存储在自动创建的表中），如果已过时，则执行该命令。

为了更新存储库中的metadata.sql，我们在本地运行此升级，然后提取完整的数据库元数据。

唯一经常发生的事情是忘记提交metadata.sql，但这不是一个主要问题，因为它很容易在构建过程中进行测试，而且唯一可能发生的事情是使用以下命令进行新安装过时的数据库并在第一次使用时对其进行了升级。

此外，我们不支持降级，但这是设计使然，如果更新出现问题，我们会恢复以前的版本并修复更新，然后再重试。

Answer 13

我创建以构建版本命名的文件夹，并将升级和降级脚本放在其中。例如，您可能有以下文件夹：1.0.0、1.0.1 和 1.0.2。每个版本都包含允许您在版本之间升级或降级数据库的脚本。

如果客户或顾客致电您询问版本 1.0.1 的问题，而您使用的是 1.0.2，则将数据库恢复到他的版本不会有问题。

在您的数据库中，创建一个名为“schema”的表，在其中放入数据库的当前版本。然后编写一个可以升级或降级数据库的程序就很容易了。

就像 Joey 说的，如果你在 Rails 世界中，就使用 Migrations。:)

Answer 14

对于我当前的 PHP 项目，我们使用 Rails 迁移的想法，并且我们有一个迁移目录，其中保存文件标题“migration_XX.sql”，其中 XX 是迁移的编号。目前，这些文件是在更新时手动创建的，但它们的创建可以轻松修改。

然后我们有一个名为“Migration_watcher”的脚本，正如我们在 pre-alpha 中一样，该脚本当前在每个页面加载时运行，并检查是否存在新的 migration_XX.sql 文件，其中 XX 大于当前的迁移版本。如果是这样，它将针对数据库运行最大数量的所有迁移_XX.sql 文件，瞧！架构更改是自动化的。

如果您需要恢复系统的能力，则需要进行大量调整，但它很简单，并且迄今为止对于我们相当小的团队来说一直运行良好。

Answer 15

我建议在“脚本”方面使用 Ant（跨平台）（因为它实际上可以通过 jdbc 与任何数据库通信），并在源存储库中使用 Subversion。Ant 允许您在进行更改之前将数据库“备份”到本地文件。1.备份现有的DB模式通过ANT 2归档。版本控制到颠覆存储库通过ANT 3。通过 Ant 发送新的 sql 语句到 db

Answer 16

Toad for MySQL 有一个名为架构比较的功能，可让您同步 2 个数据库。这是我迄今为止使用过的最好的工具。

Answer 17

恕我直言，迁移确实有一个很大的问题：

从一个版本升级到另一个版本效果很好，但是如果您有数百个表和很长的更改历史记录（就像我们一样），则对给定版本进行全新安装可能会花费很长时间。

运行从基线到当前版本（针对数百个客户数据库）的整个增量历史记录可能需要很长时间。

Answer 18

我喜欢这样的方式 伊伊 处理数据库迁移。迁移基本上是一个 PHP 脚本实现 CDbMigration. CDbMigration 定义一个 up 包含迁移逻辑的方法。还可以实施 down 支持逆转迁移的方法。或者， safeUp 或者 safeDown 可用于确保迁移是在事务上下文中完成的。

Yii 的命令行工具 yiic 包含对创建和执行迁移的支持。可以逐个或批量应用或撤消迁移。在 PHP 类的代码中创建迁移结果实现 CDbMigration, ，根据用户指定的时间戳和迁移名称进行唯一命名。先前应用于数据库的所有迁移都存储在迁移表中。

欲了解更多信息，请参阅 数据库迁移 手册中的文章。

Answer 19

尝试 db-deploy - 主要是一个 Java 工具，但也适用于 php。

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

Answer 20

有一个命令行 mysql 差异 比较数据库模式的工具，其中模式可以是磁盘上的实时数据库或 SQL 脚本。它适用于大多数架构迁移任务。