C#/SQL云应用程序-不同版本的客户端
本文关键字：版本 客户端 SQL 应用程序 | 更新日期: 2023-09-27 18:19:37
我正在为位于不同物理位置的一组用户设计一个小型应用程序。应用程序将连接到云中的中央数据库（好吧，在中央服务器上——想想云，但不是真正的云）。数据库集中保存，以便于在中心位置进行备份。我是一个经验丰富的开发人员，连接方法、代码和其他因素真的不是问题所在。
然而，我需要允许在用户认为合适的时候将应用程序升级到新版本，而不是按照任何计划。在新的更新中，数据库架构可能会发生更改。因此，我将遇到用户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服务后面的代码。您必须仔细设计每个升级步骤，以保持与以前版本的向后兼容性。两个重叠的版本很可能使用相同的存储（相同的DB）。如果用户使用v1.2 API添加项目，他通常希望稍后使用v1.1 API找到它，尽管可能缺少v1.2特有的一些属性。您的后端必须决定如何处理使用v1.1 API添加/编辑的项目的v1.2属性（例如，默认值、NULL等）。正如我所说，这很难，没有银弹。有时，您可能不得不咬紧牙关，不提供后台兼容（v1.2中添加的项目对v1.1 API客户端不可见，即使用单独的存储，不同的DB）。
当您的客户端直接访问数据库时，情况如何？也就是说，没有明确的API，客户端直接连接到数据库。你成功的机会大大减少了。。。您可以使用API与DB进行交互，例如，仅使用所有的存储过程。通过使用模式作为名称空间，您可以提供版本控制，例如exec [v1.1].[getProducts]与exec [v1.2].[getProducts]。但是它繁琐、困难、容易出错，而且您可以告别大多数开发工具向导、orms和其他提示。