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