Database 在更新网站时更改数据库表

这似乎是每个web应用程序中不断出现的问题；您正在改进后端代码，因此需要修改数据库中的一个表。在开发系统上手动执行没有问题，但是当您将更新的代码部署到生产服务器时，它们也需要自动更改数据库表

我已经看到了处理这些情况的各种方法，它们都有各自的好处和问题。大致来说，我得出了以下两种可能性

专用更新脚本。需要手动启动更新。需要按照预定义的顺序完成所有表的更改（严格的发布计划，数据库上没有简单的快速修复）。通常需要维护一个单独的更新过程，并以某种方式记录和管理版本号。好处是它不会影响正在运行的代码

在运行时检查表属性，并在需要时修改它们。不需要手动交互，而且表的更改可能以任何顺序发生（因此数据库上的快速修复很容易部署）。另一个好处是代码通常更易于维护。明显的问题是，它需要检查的表属性比需要检查的要多得多

---

在应用程序更新时，是否有其他处理更改数据库表的一般可能性或方法？

我将分享我所看到的最有效的方法。它只是扩展了你的第一个选择

在生产环境中更新模式时，我通常会看到以下步骤：

取下前端应用程序。这将防止在架构更新期间写入任何数据。我们不希望由于关系混乱或表突然与应用程序不同步而导致写入失败

可能会断开数据库连接，因此无法建立连接。有时，有些代码正在使用您甚至不知道的数据库

按照第一个选项中所述运行脚本。这当然需要仔细的计划。您是对的，您需要一个预定义的顺序来应用更改。我还要指出，您经常需要两组脚本，一组用于模式更新，另一组用于数据更新。例如，如果要添加不可为null的字段，可以先添加可为null的字段，然后运行脚本以输入默认值

手头有回滚脚本。这是至关重要的，因为您可能会进行您认为需要的所有更改（因为这些更改在开发中都非常有效），然后在将应用程序重新联机之前发现应用程序不起作用。有一个退出策略是很好的，这样你就不会处于“哦，糟了，我们破坏了应用程序，我们已经离线好几个小时了，我们该怎么办？！”

确保您准备好了备份，以防（4）变得非常糟糕

协调应用程序更新与数据库更新。通常先进行数据库更新，然后发布新代码

（可选）许多公司都会进行部分推出以进行测试。我从来没有这样做过，但是如果您有5个应用程序服务器和5个数据库服务器，那么您可以首先部署到1个应用程序/1个数据库服务器，然后看看它是如何运行的。然后，如果它是好的，你继续与其余的生产机器

---

找出最适合你的方法肯定需要时间。根据我做大量生产数据库更新的经验，没有什么灵丹妙药。最重要的是在跟踪更改（如您所述的版本控制）方面花时间并严格遵守规则。

这是一个相当开放的问题。您遇到的问题是什么？问题是，我目前正在实现一个没有更新系统的新web应用程序，希望了解处理数据库更新的最佳方法。它是基于PHP/MySQL的，但这并不重要。