Azure移动服务/Azure表:如何处理“成员”列表

您使用移动服务的事实改变了一切。对不起,我一开始读你的帖子时没有注意到。

Mobile Services使用的默认数据存储是SQL Server,它允许对特定表进行多重索引。 在这种情况下,我建议使用以下数据模式:

• 一个“事件”表,其中包含表示事件唯一Id的Id列以及存储事件信息的其他字段(描述等)
• 具有EventId字段和UserId字段的EventMembers表(均已索引)

假设我们有一个Id为1的事件,用户Id为User1和User2的用户正在参与。 您将在“事件”表中有以下记录:

id: "1"
description: "event with id 1"

在EventMembers表中,您将有两条记录:

eventid: "1"
userid: "User1"

eventid: "1"
userid: "User2"

因为eventid和userid都是索引列,所以可以查询表以检查哪些用户参与了事件以及特定用户参与了哪些事件。

正如您可能知道的那样,Azure表存储不是关系型的,不允许除主集群(readpartitionkey和rowkey)之外的任何索引。 如果要通过在filter子句中包含字段来查询表,则该字段必须是partitionkey或partitionkey与rowkey。(事实上,您可以通过其他字段进行过滤,但在性能方面的结果将是灾难性的)。

在您的情况下,我建议创建两个表:

• 以事件id为关键字的Events表,并将事件成员的信息放在非索引字段中
• 将userid作为关键字,将eventid作为非索引字段的Members表

向事件添加/删除成员时,需要同时写入两个表。 如果要按成员进行筛选,请查询Members表。如果要按事件id进行筛选,请查询event表。

我知道,这听起来像是浪费存储空间和重复信息,但这是为可扩展性和性能付出的代价。使用关系数据库会容易得多,但不会受益于Azure表存储提供的几乎无限的可扩展性。

当做

安德莉亚