我正在为不同物理位置的一组用户设计一个小应用程序。该应用程序将连接到云中的中央数据库（好吧，在中央服务器上 - 想想云，但不是真正的云）。集中保存数据库以便于在中心位置进行备份。我是一名经验丰富的开发人员，连接方法，代码和其他因素确实不是问题。
但是，当用户认为适合时，我需要允许应用程序升级到更新版本 - 而不是任何类型的计划。在新的更新中，数据库架构可能会更改。所以我将遇到用户A下载新版本和升级数据库的问题。然后，用户B，C和D在尝试访问数据库时会收到错误，因为表/视图可能不存在。
我考虑过在同一台服务器上维护不同的数据库。当用户A升级时，我们将从DB_V1“推送”他们的数据库值到DB_V2，他们将使用那个。用户B，C＆amp;在他们决定升级之前，D仍然可以使用DB_V1。最终，当所有用户都已从该数据库升级时，可以删除DB_V1。
我是否可以在云计算应用程序中找到处理此问题的最佳方法？当客户端可能位于不同版本时，如何正常完成/处理数据库更新？
答案 0 :(得分：0)
不幸的是，它很难并且没有银弹。游戏名称是版本控制，您必须支持重叠版本。您的访问API必须进行版本控制。例如。考虑客户端通过REST接口与“云”进行通信。 API的根URL可能与http://example.com/api/v1.1/类似。部署新版本时，您还将API移至http://example.com/api/v1.2/并公开此新API中的新功能，但也继续支持旧版本。在客户端升级到足够数量的客户端之后，您将为客户端提供一段宽限期以升级到v1.2，并在将来某个时间退出v1.1。 The REST API Design Handbook是该主题的一个很好的资源。
现在真正的问题是你的后端，即URL服务背后的代码。您必须仔细设计每个升级步骤，以保持与先前版本的向后兼容性。两个重叠版本很可能会使用相同的存储（相同的DB）。如果用户使用v1.2 API添加项目，他通常希望稍后使用v1.1 API找到它，尽管可能缺少某些特定于v1.2的属性。您的后端必须决定如何处理使用v1.1 API添加/编辑的项目的v1.2属性（例如，默认值，NULL等）。正如我所说，这很难，而且没有银弹。有时您可能需要咬紧牙关并且不提供反向比较（v1.2添加的项目对于v1.1 API客户端是不可见的，即使用单独的存储，不同的DB）。
客户端直接访问数据库的情况如何？ IE浏览器。没有明确的API，客户端直接连接到数据库。你成功的机会大大减少了......你可以让你与数据库的交互使用API，例如。仅使用所有内容的存储过程。通过使用模式作为命名空间，您可以提供版本控制，例如。 exec [v1.1].[getProducts]与exec [v1.2].[getProducts]。但是很麻烦，很难，容易出错，你可以亲吻再见大多数开发工具向导，动作和其他口哨和铃声。