推送新版本时处理数据库架构更改

在繁重的开发期间，数据库架构会快速且连续地发生变化，并且随着我们每周对beta版本的推动而来，架构已发生了如此大的变化，以至于唯一明智的选择是删除所有我可以并且可以从我的开发数据库中复制新版本。显然，一旦启动，这是行不通的，因为破坏生产数据是灾难的根源，所以我想知道那里有什么策略来管理从一个版本/修订到另一个版本的数据库模式更改？

我发现或经历过的一些：

1. 直接从一个数据库到另一个数据库的nuke-and-dump（我现在在做什么）
2. 使用通过脚本或手动运行的SQL语句维护UPDATE.sql文件。
3. 在活动数据库中维护具有相应“ db-schema-version”值的update.php文件

第三种选择似乎是最明智的选择，但是仍然存在构造错误的SQL查询使中间脚本失败的可能性，从而使数据库处于半更新状态，因此需要还原备份。

看来这是没有问题的，但是确实发生了，因为我们作为一个团队，我们使用phpMyAdmin，我什至不能依靠自己记住复制执行的SQL语句以粘贴到update.php文件中。导航到另一页后，我必须手动重新编写SQL语句，或者撤消更改并再次执行。

我想我希望找到一种不会影响我们已建立的开发工作流程的解决方案？

自动化。自动化。自动化。

您使用正确的数据库版本号在正确的轨道上，但是我将走得更远，使代码明确知道它期望针对的模式（例如，通过提交实际的DDL脚本并让更新程序对其进行解析） ）; 然后，在更新时，无论从哪个版本更新到哪个版本，都仅需要根据需要通过数据库元数据和INSERT / DROP / ALTER发现现有方案。（您还可以在数据库本身中保留一个明确的版本号，并通过安装程序提供整个架构历史记录，这样您甚至不需要架构发现。）

更新SQL脚本中潜在的语法错误是一个问题，但是您可以通过验证更新程序只能生成正确的DDL语句来解决此问题。（在企业软件开发中，正式的证明几乎是不值得的-付出太多的努力而过少的保证-但我觉得数据库完整性是少数几个例外之一：基本的SQL并不是一种特别难于形式化的语言，而且它的好处是保护生产数据是如此之大，以至于几乎所有一次性的前期工作都是合理的，特别是如果它必须用于无人值守的安装时，）

数据库模式版本控制是一种解决方法-每个版本对数据库只有一个更改，或者至少可以整体还原。DBDeploy是使它自动化的出色工具。

我学到的一些有用的东西是：

1. 始终在本地测试您的更改，并用它测试您的代码，仅ALTER通过是不够的
2. 您需要同步哪个先进行更改-一个简单的Wiki页面，您可以在其中“获取数字”，这对我的团队非常有用。
3. 不要试图修复损坏的更改，而要添加新的反向更改来消除它，这很容易
4. 您的代码取决于这些更改-请确保将Bug跟踪系统中的问题与数据库更改相关联。这在部署时非常有帮助。
5. 包括对CI的数据库更改-提交时将更改应用于CI数据库。另外，如果您有使用数据库的测试，请在提交时运行它们。

由于您使用的是phpMyAdmin，因此我假设您也在使用MySQL。

看一下MySQL Workbench中的EER模型图。它们对我维护和更新架构有很大帮助。

首先，您可以将模型与数据库源同步。因此，图中的更改将作为ALTER TABLE命令推送。这使您可以在图上执行模式更改，使其始终保持最新状态，同时还可以在需要时向开发数据库推送更新。

其次，您可以从数据库源反向工程EER图。通过对开发数据库进行更改并更新生产数据库，这将非常方便，因为它将计算差异。

第三，它可用于协助创建应放入“ update.sql”文件中的SQL。

缺点：

数据库触发器和约束是同步更新程序的问题。似乎不知道事物的正确顺序。外键约束通常会产生错误，但是可以通过编辑它生成的SQL来解决。

这不是数据迁移工具。纯粹是架构之外的任何更改仍将需要自定义SQL。

看一下http://south.aeracode.org —这是Django（Python框架）的DB迁移库，但是：

1. 您可以从中获得很棒的想法（甚至可以找到一个PHP克隆）
2. 您实际上可以独立于Django的其余部分来使用它来管理PHP / MySQL应用程序的表。

它还可以生成模式更新脚本。它还在大多数情况下自动处理更改撤消。