如何正确存储与Microsoft Azure表存储的数据关系?

1. 使用一个简单的映射表,就像在RDBMS中一样。每一行都包含一个Book键和一个User键。

   然后,要查找用户的所有书籍,您需要在映射表中选择书籍键,然后为每个键从书籍表中选择图书实体。您可以使用异步获取并行执行图书检索,但即便如此,这种解决方案显然无法扩展。

3. 将图书密钥存储在用户的单个属性中。同样,您已经建议了这种方法。

   如果不是因为Azure目前不支持“包含”类型查询,也就是说,你不能搜索子字符串,所以如果你想找出哪些用户拥有特定的图书,这是不可能的。有趣的是,谷歌应用引擎在其存储系统中相当透明地支持这一点,并将为您索引列表。无论如何,您仍然需要使用此方法检索每本书的数据。

4. 使用Azure表存储的“无模式”特性将关联的Book密钥存储为单独的属性。例如,一个用户实体可能看起来像这样:

   { Name: "User1", Book_4325: true, Book_5123: true }

   而另一个可能看起来像这样:

   { Name: "User2", Book_5346: true, Book_8753: true, Book_6135: true }

   然后,如果你确实想找到拥有特定书籍的所有用户,你可以选择该特定属性为真的位置(好吧,它只需要真正存在)。

   这样做的明显缺点是它有点脆弱,你需要摆弄属性名中的键,而且你无法使用StorageClient的标准方法——你必须自己动手。此外,Azure仅支持实体上的255个属性。尽管如此,我认为它可以很好地扩展——尽管我从未尝试过。

在所有这些选项中,我会说你要使用的选项2是最好的,因为它目前由Azure支持,你通常可以用更少的查询来实现一切。

考虑到原子事务已经过时,你只需要仔细审查你的用例,就可以决定如何以及何时更新数据。我几乎可以保证,你能够接受“最终一致”的情况,并考虑到你的映射表可能并不总是100%最新的。

如果在主表的同时更新映射表中的数据变得过于昂贵,您可以将一条消息放入队列,并让一个工作角色异步地为您执行更新。

你不知道。这是一场很好的综合比赛 white paper (.docx链接),其中包含有关最佳实践的部分。但是,您应该使用Table进行非关系属性包或ORM类型设计。如果你想在云中使用关系型,你应该使用 SQL Azure Database .

这是另一个 good article 关于无模式存储与关系存储。这是给a的 different schema free cloud storage offering