我正在为不同物理位置的一组用户设计一个小型应用程序。该应用程序将连接到云中的中央数据库（嗯，在中央服务器上——想想云，但不是真正的云）。数据库集中保存，以方便在中央位置进行备份。我是一位经验丰富的开发人员，连接方法、代码和其他因素确实不是问题。
但是，当用户认为合适时，我需要允许将应用程序升级到较新的版本——而不是按照任何时间表。在新的更新中，数据库架构可能会发生变化。所以我将遇到用户A下载新版本并升级数据库的问题。用户 B、C 和 D 在尝试访问数据库时会出现错误，因为表/视图可能不存在。
我考虑过在同一台服务器上维护不同的数据库。当用户 A 升级时，我们会将他们的数据库值从 DB_V1“推送”到 DB_V2，他们将使用那个。用户 B、C 和 D 在决定升级之前仍然可以使用 DB_V1。最终，当所有用户都从该数据库升级后，可以删除 DB_V1。
我可以对在云应用程序中处理此问题的最佳方法有一些想法吗？当客户端可能使用不同的版本时，通常如何完成/处理数据库更新？
不幸的是，这很难，而且没有灵丹妙药。游戏的名称是版本控制，你必须支持重叠版本。您的访问 API 必须进行版本控制。例如。考虑客户端通过 REST 接口与“云”通信。API 的根 URL 可能类似于http://example.com/api/v1.1/. 当您部署新版本时，您还将 API 移动http://example.com/api/v1.2/到此新 API 中并公开新功能，但也继续支持旧的 v1.1。您给客户一段时间的宽限期以升级到 v1.2，并在未来某个时间停用 v1.1，在足够数量的客户升级后。REST API 设计手册是关于该主题的一个很好的资源。
现在真正的问题是您的后端，即位于 URL 服务后面的代码。您必须仔细设计每个升级步骤，以保持与以前版本的向后兼容性。两个重叠版本很可能会使用相同的存储（相同的数据库）。如果用户使用 v1.2 API 添加项目，他通常希望稍后使用 v1.1 API 找到它，尽管可能会丢失一些特定于 v1.2 的属性。您的后端必须决定如何处理使用 v1.1 API 添加/编辑的项目的 v1.2 属性（例如，默认值、NULL 等）。正如我所说，这很难，也没有灵丹妙药。有时您可能不得不硬着头皮不提供任何反向兼容性（v1.2 添加的项目对 v1.1 API 客户端不可见，即使用单独的存储，不同的数据库）。
当您的客户直接访问数据库时，情况如何？IE。没有明确的 API，客户端直接连接到数据库。您成功的机会已大大减少...您可以使用 API 与数据库进行交互，例如。对所有事情都只使用存储过程。通过使用模式作为命名空间，您可以提供版本控制，例如。exec [v1.1].[getProducts]与exec [v1.2].[getProducts].. 但它繁琐、困难、容易出错，您可以告别大多数开发工具向导、orms 和其他花哨的东西。