我有一些用户可编辑的数据，经常阅读和偶尔阅读。目前，我正在考虑将其序列化为JSON并将其存储在Azure上的Blob存储中或构建它（以与当前不同的方式）并将其存储在表存储中。
我最关心的是＆＃34;升级＆＃34;数据。例如，今天MyDataObject类有一些复杂的属性MyCoolProperty（只是意味着它不是原始类型）。明天，我发现需求已经改变，现在我的对象需要包含这些复杂对象的列表，所以现在我必须找到一种方法来升级我的数据以允许这个新的需求而不破坏可能不是的现有应用程序能够同时更新。
所以我真正要求的是：是否有任何资源，社论，框架或最佳实践与如何成功地保持业务发展同时轻松（或相对容易）响应需求变化
答案 0 :(得分：1)
Anthony，我们在开发Cognito Forms时遇到了类似问题，该问题仅在Azure Table Storage上运行。我们将所有实体存储为JSON，使用表存储属性作为查询的索引。虽然我们的版本控制解决方案可能不适合您，但它对我们来说效果很好，所以我将在此处对其进行描述：
Func<string, string>，它将转换应用于JSON并代表该类型的特定新版本然后我们能够按需升级，因为从表存储中查询实体，但也能够查询表存储以查找“过时”的实体以执行后台更新。由于我们有数百万个实体，因此将这些实体作为更新的一部分转换为没有停机时间的系统是不切实际或不可行的。由于我们的服务层服务器由Azure自动升级到最新版本，因此他们只是在不中断服务的情况下即时开始升级JSON。
在您的具体情况下，您似乎可以应用类似的方法，但您必须找到一个创造性的解决方案来并行处理多个应用程序共享相同的数据。最终，如果具有单独发布周期的两个独立系统正在编辑相同的确切实体，则没有解决方案可以完全保护您的冲突。但是，您可以存储多个版本和/或同时支持升级和降级修订逻辑。
希望这有帮助！