我习惯于SQL和关系设计，所以我对我当前的项目感到有些困惑。这是怎么回事：
有些名为“Bubbles”的东西与Google Circle基本相同。它们是用户定义的，可以将任何PFUser作为“成员”。
然后有“帖子”。每个帖子都有一个可见性设置，它是一组PFUser（或气泡）。
应用程序的工作原理是用户制作他/她的气泡，然后可以浏览Feed / post to bubbles。这个问题变得棘手的原因是：当应用程序启动并且我想查询特定用户的帖子时，我首先需要找到属于他们的气泡（很简单），然后我需要让用户进入这些气泡，然后我需要查询这些用户的帖子，然后我需要确保我在那些帖子的可见性。我尝试制作云代码函数，但由于异步调用弄乱了for循环的索引，它无法填充字典的帖子部分。
无论如何，我正在拔出我的头发试图找出最好的nosql方法来做到这一点。任何帮助，Parsers？
答案 0 :(得分：9)
那里有一个大问题。我不能为你创建一个模型，但我可以给你一些关于你需要思考的提示。
首先，正如您似乎已经发现的那样，您需要停止考虑此任务的关系设计术语。对于所有在SQL数据库中受过教育的人（我们大多数人，仍然是），这是一个漫长的过程。许多NoSQL方法在我们的关系思想中都表现不佳。
第二，您需要专注于数据提取。使用该模型无疑会在您的脑海中形成（甚至可能实现），快速提取所需数据所需的查询变得非常复杂。由于您的客户可能主要是（仅限？）移动设备，因此您需要将查询次数和计算开销降至最低。
第三，如果您确信您的应用可能会出现在图表中并且变得非常受欢迎（假设您没有设计企业应用），则需要设计可扩展性。不一定实现它完全如此，但至少设计，以便您可以通过改进它来构建初始设计，而不是在应用程序变得流行时完全重建它（如果您的努力无法跟上不断增长的用户群，那么就有可能遭受彻底的灾难。）
作为一个典型的例子;如果您需要由用户列表创建的帖子列表，则不必首先去获取用户，然后查询这些用户的帖子。您准备架构，以便将此帖子列表（以及通常请求的其他结果列表）作为架构的一部分进行准备。这可以是feed的表（解析类）。每个用户一条记录，该记录包含预先准备的Feed数组。每次我关注的用户写新帖时都需要更新。跟随帖子的作者的所有其他用户的记录也是如此！在那里，我只是在你的关系思想中打了一个坏话，不是吗？ ： - ）
现在，对于实现细节，我建议您看一下NoSQL架构设计示例。我找到了＆＃34; Twissandra＆＃34; （在Apache Cassandra中实现的Twitter克隆）是如何设计NoSQL的非常好的入门读物。特别是因为Twitter是一个用例，我们可以轻松地与之相关。即使Parse由MongoDB支持，而不是Cassandra，大多数原则仍然存在：http://www.rackspace.com/blog/cassandra-by-example/
此外，比较本演示文稿中的第6页和第7页，可以很好地了解SQL和NoSQL之间不同的这种模式设计： https://speakerdeck.com/mongodb/mongodb-dc-2012-schema-design-by-example
我建议您在阅读这些（可能还有其他）文章后尝试（重新）设计您的架构，然后根据需要在此处询问与您的实施相关的更多具体问题。