我习惯了 SQL 和关系设计，所以我对我当前的项目有点难。这是它的过程:
有一些叫做“气泡”的东西，其运作方式与 Google Circle 基本相同。它们是用户定义的，并且可以将任何 PFUser 作为“成员”包含在其中。
然后是“帖子”。每个帖子都有一个可见性设置，它是一个 PFUsers(或气泡)数组。
该应用程序的工作原理是用户制作他/她的气泡，然后可以浏览提要/发布到气泡。这变得棘手的原因是:当应用程序启动并且我想查询特定用户的帖子时，我首先需要找到属于他们的气泡(很容易)，然后我需要让用户进入这些气泡，然后我需要查询这些用户的帖子，然后我需要确保我在这些帖子的可见性中。我尝试制作一个云代码函数，但由于异步调用弄乱了 for 循环的索引，它无法填充字典的帖子部分。
无论如何，我目前正在努力找出最好的 nosql 方法来做到这一点。任何帮助，解析器？
最佳答案
有一个很大的问题。我无法为你创建模型，但我可以给你一些关于你需要如何思考的提示。
第一 ，正如您似乎已经发现的那样，您需要停止在此任务的关系设计方面进行思考。对于所有首先学习 SQL 数据库的人(我们中的大多数人，仍然如此)，这是一个漫长的过程。许多 NoSQL 方法在我们的关系思维中都留下了不好的印象。
第二 ，您需要专注于数据提取。毫无疑问，使用您在脑海中形成(甚至可能实现)的模型，提取所需数据所需的查询很快变得非常复杂。而且由于您的客户可能主要是(仅？)移动设备，您需要将查询数量和计算开销减少到最低限度。
第三 ，如果您相信您的应用程序可以登上排行榜并广受欢迎(假设您不是在设计企业应用程序)，那么您需要针对可扩展性进行设计。不一定要完美地实现它，但至少要为它设计，以便您可以通过改进它而不是在应用程序流行时完全重建它来构建您的初始设计(如果您的努力跟不上，则可能会面临彻底的灾难)不断增长的用户群)。
作为一个典型的例子；如果您需要由用户列表创建的帖子列表，您不必先去获取用户，然后查询这些用户的帖子。您准备好您的架构，以便此帖子列表(以及其他通常要求的结果列表)已经准备好作为您架构的一部分。这可以是提要的表(解析类)。每个用户一个记录，该记录包含一个预先准备好的提要数组。每次我关注的用户写新帖子时都需要更新。关注帖子作者的所有其他用户的记录也是如此!在那里，我刚刚在你的关系头脑中留下了不好的印象，不是吗？ :-)
现在，对于实现细节，我建议您查看 NoSQL 模式设计示例。我发现“Twissandra”(在 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
我建议您在阅读这些(可能还有其他)文章后尝试(重新)设计您的架构，然后在需要时在 SO 上提出与您的实现相关的更具体问题。
关于database-design - 挣扎于 nosql/Parse 数据模型设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22775613/