嵌套包含 Parse.com答案

【问题标题】：Nested Include Parse.com嵌套包含 Parse.com
【发布时间】：2014-04-02 01:44:46
【问题描述】：

我有一个UserToMessage 表，它有一个指向名为thisUser 的用户指针和一个指向名为msg 的消息的指针

message table 有一个指向名为creator 的用户的指针。当我查询UserToMessage我[includeKey:@"message"]

我也想以某种方式[includeKey:@"creator"]...

【问题讨论】：

@ApperleyA 不要“什么？......”我......

标签： ios objective-c parse-platform

【解决方案1】：

这会起作用。

PFQuery *query = [PFQuery queryWithClassName:@"UserToMessage"];
[query includeKey:@"msg"];
[query includeKey:@"msg.creator"];

// Add constraints on query
...
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) {
    if(error) return;
    // Do action
    ...
}];

【讨论】：

【解决方案2】：

[includeKey:@"message.creator"]

您甚至可以更深入地执行此操作：message.creator.mother - 但仅此而已。

【讨论】：

【解决方案3】：

与其问自己如何在类似 JOIN 的查询中包含来自多个表的信息，不如问自己是否设计了应用所需的数据库模型。

你所写的关于你的模型的内容听起来很像 SQL。不过没关系，因为大多数来到 parse.com 和其他 NoSQL 支持的服务的人都来自 SQL 世界。但是，简单地将 SQL 数据库设计转移到 Parse 中通常不会提供最佳解决方案。

相反，首先关注查询并确定它们需要返回哪些数据。如果你发现你需要查询中返回的 3 个不同类的数据，那是模型的错误。为便携设备开发应用，需要关注查询性能和计算开销。

您应该以这样一种方式设计您的数据库模型，即您的大部分（如果不是全部）数据都可以在尽可能少的查询中访问。最好是一个。

此问题的典型解决方案围绕非规范化和最终一致性展开。例如，在类似 Twitter 的应用程序中，如果您想检索您关注的人发布的帖子，则无法通过首先查询一个人的“关注”然后查询推文表以获取所有发布的推文来获得此信息被那些人。它可能适用于一些关注和帖子，但如果您关注 100.000 人，这将是不可行的。

在 NoSQL 场景中，当有人发布推文时，该帖子将存储在推文表中，您可以将指向该推文的指针存储在我的提要对象和每个提要对象中的数组中以及所有关注推文作者的人！

我知道从 SQL 数据库的角度来看，这似乎很奇怪（疯狂，甚至），但对于 NoSQL 系统而言并非如此。如果我后来删除了一条推文，那么这条推文可能需要从 359.000 个提要对象中删除（如果我是巴拉克奥巴马）。这不会是立竿见影的——因此是“最终的一致性”。

我建议您坐下来拿着笔和纸，根据您需要检索的数据重新考虑您的数据库模型。

【讨论】：

我是那些有 SQL 背景的人之一，你是对的，底部的示例确实看起来很疯狂。我不是想在这里反驳你，我只是想了解更多，但这是真的吗？如果我们看看今天的规模，奥巴马拥有超过 4000 万的追随者 - 为奥巴马创建的每条推文创建 4000 万条新记录实际上是否比让个人进行额外查询更快？再说一次，不是想反驳你 - 我很想详细了解这一点:)谢谢你，先生！
好吧，“更快”并不是真正的问题。您将创建 40M 记录的时间与查询 40M 记录（如果所有关注者都收到推文）进行比较。但是当你设计数据库时你应该记住的是如何最小化每个用户的工作；意思是移动客户端。如果创建 40M 记录（极端示例，但仍然如此）很耗时，那么这对客户端来说无关紧要，因为这一切都发生在服务器上。但是每个额外的（非）必要的查询都会减慢客户端的速度，并且用户体验会受到影响。
详细说明：当使用像 Twitter 这样的大规模时，几乎任何解决方案都可能看起来很疯狂，因为卷本身很疯狂。想象更传统的方法：当我打开我的 Twitter 应用程序来查看我的信息流时，系统必须查询我所有的数百个关注者才能获得他们的最新帖子。不是发帖，是发帖。然后，它们都必须按时间顺序排序，然后才能呈现在流中。那是一个大手术。但更糟糕的是：该应用程序不仅显示推文本身，还显示推文的屏幕名称和图片。会有很多查询...
那么你会“内联”多少信息？如果我们在奥巴马发推文时将推文附加到每个关注者的数组中，我们如何处理奥巴马的详细信息（例如您提到的姓名和缩略图）？这是一个类似的交易，会被“内联”吗？它在哪里结束..？我们是否只是将 ID 添加到这些数组中，以便用户仍然需要查询数据，但使用简单的键比较而不是范围搜索？对不起..也许我们应该在别处举行这次谈话：P

【解决方案4】：

好的，这个问题真的很令人困惑。如果我理解正确，您想查询UserToMessage 表并包含两个条件？如果是这样，您可以这样做：

[query whereKey:@"msg" equalTo:MSG_POINTER];
[query whereKey:@"thisUser" equalTo:PF_USER_POINTER];

如果不是这种情况，请更新您的问题以反映您的确切需求。

【讨论】：