Database 如何在更新数据库和应用程序时最大限度地减少应用程序停机时间

我们目前为一家休闲和旅游公司提供电子商务解决方案。每次我们发布一个版本，我们都必须在更新数据库模式和数据访问代码时关闭电子商务站点。我们使用定制的ORM，其中每个数据实体负责自己的CRUD操作。这是通过基于数据实体中的属性动态生成SQL来实现的

例如，地址的数据实体将是

[tableName="address"]
public class address : dataEntity
{
  [column="address1"]
  public string address1;
  [column="city"]
  public string city;
}

因此，如果我们向数据库中添加一个新列，我们必须更新数据库的模式，还必须更新数据实体

正如您所预料的，业务人员对这次中断不太满意，因为这会影响他们的现金流。操作人员不高兴，因为他们必须处理数据库和应用程序升级时的高压时间。程序员们感到不安，因为他们继承的遗留系统不断给他们带来麻烦

---

你们这些聪明人有什么建议吗？

第一个答案显然是，不要使用ORM。只有应用程序程序员认为他们很好。像其他人一样学习SQL:）

好吧，回到现实。如何阻止您将所有架构更改限制为仅添加。然后，您可以随时更新数据库模式，并且只安装重新编译的应用程序，直到数据库更新后的安全时间（我发现早上6点最适合）。如果您必须删除内容，请执行相反的步骤-安装新应用程序时保持模式不变，然后从模式中删除位

当您推出更改时，您总是会有一段很紧张的时间，但至少您可以通过两个更容易理解的部分来更好地管理它。DBA可以更新现有应用程序的模式

---

缺点是，您必须更加有条理，但在处理生产服务器时，这不是一件坏事，您当前应该对此进行认真的组织。

支持此方案将为您的环境和/或流程和/或应用程序增加大量复杂性

您可以运行一个复杂的更新过程，其中应用程序代码足够智能，可以同时在旧模式和新模式上正确运行。然后可以先更新应用程序，然后更新模式。第三步可能是迁移任何数据，同样，应用程序必须能够使用这些数据。在这种情况下，您只需在升级应用程序所需的时间内“删除”应用程序，这可能仅为秒，具体取决于升级中涉及的文件和计算机数量

---

在大多数情况下，最好让应用程序/环境/流程保持简单，并在一天/一周/一个月的缓慢时间与市中心生活在一起。几乎所有的应用程序都需要“关闭”以便“定期计划维护”。

我强烈反对这一点。解决方案与您的解决方案没有什么不同，只是我说，在应用程序运行之前，在DB中运行的时间稍长一些。顺便说一句，我在911呼叫中心工作，我们根本就不能停工。我们拆分容错对，更新数据库，更新应用程序，然后将正在运行的系统故障转移到更新的系统。如果我们必须撤销我们的应用程序，那么切换回旧应用程序、保持新的DB模式就容易多了。当然，ORM使这变得越来越困难，但这更是一个我们必须处理的实现问题。像其他任何事情一样，使用正确的工具完成正确的工作。。。例如“示例”。。。阅读密集型产品可以使用大多数ORM中提供的一级和二级缓存功能，并避免调用从未产生新答案的数据库。另一方面，写操作繁重的应用程序可能会发现将写操作（特别是复杂的写操作）卸载到数据库更有意义。