这似乎是每个 Web 应用程序中不断出现的问题。您正在改进后端代码，并且需要更改数据库中的表才能这样做。在开发系统上手动执行没有问题，但是当您将更新的代码部署到生产服务器时，它们也需要自动更改数据库表。
我见过各种处理这些情况的方法，都有各自的好处和问题。粗略地说，我得出了以下两种可能性；
专用更新脚本。需要手动启动更新。要求以预定义的顺序完成所有表更改（严格的发布计划，数据库上没有简单的快速修复）。通常需要维护一个单独的更新过程以及一些记录和管理版本号的方法。好处是它不会影响正在运行的代码。
在运行时检查表属性并在需要时更改它们。无需手动交互，表更改可能以任何顺序发生（因此对数据库的快速修复很容易部署）。另一个好处是代码通常更容易维护。明显的问题是它需要检查表属性的次数比它需要的多得多。
是否有任何其他一般可能性或方法来处理在应用程序更新时更改数据库表？
我会分享我看到的效果最好的东西。它只是在您的第一个选项上进行扩展。
我在生产中更新模式时通常看到的步骤：
删除前端应用程序。这可以防止在模式更新期间写入任何数据。我们不希望写入失败，因为关系混乱或表突然与应用程序不同步。
可能会断开数据库连接，因此无法建立连接。有时，您甚至不知道使用您的数据库的代码！
按照您在第一个选项中的描述运行脚本。这肯定需要仔细规划。没错，您需要一个预定义的订单来应用更改。此外，我经常会注意到您需要两组脚本，一组用于模式更新，一组用于数据更新。例如，如果要添加不可为空的字段，则可以先添加可空字段，然后运行脚本以输入默认值。
手头有回滚脚本。这是至关重要的，因为您可能会做出您认为需要的所有更改（因为它们在开发中都运行良好），然后在将应用程序重新上线之前发现应用程序无法正常工作。有一个退出策略是很好的，这样你就不会陷入“哦，废话，我们破坏了应用程序，我们已经离线好几个小时了，我们该怎么办？！”
确保您已准备好备份，以防 (4) 变得非常糟糕。
协调应用程序更新与数据库更新。通常您会先进行数据库更新，然后再推出新代码。
（可选）许多公司进行部分推出以进行测试。我从来没有这样做过，但是如果您有 5 个应用程序服务器和 5 个数据库服务器，您可以先部署到 1 个应用程序/1 个数据库服务器，然后看看情况如何。然后，如果它很好，您继续使用其余的生产机器。
找出最适合您的方法肯定需要时间。根据我进行大量生产数据库更新的经验，没有灵丹妙药。最重要的是花时间并在跟踪更改（如您提到的版本控制）方面受到纪律处分。