Question

专门针对Firestore，为什么要将其根集合构造为userId文档，其中包含一个userPosts子集合，该子集合包含每个用户的帖子。为什么不只通过userId将帖子保存在根集合和查询过滤器中？

例如，许多关于结构化数据的StackOverflow Q / A建议具有以下内容：

'users':{
  'user1@gmail.com': {
    'username': 'user1'
  }
},
'posts':{
  'user1@gmail.com': {
    'userPosts':{
      'post1': {
         'content': 'post1 content'
       },
      'post2': {
         'content': 'post2 content'
       },
    }
  }
}

其中“用户”和“帖子”是集合，而“ userPosts”是子集合，查询为：

db.collection('posts').doc('user1@gmail.com').collection('userPosts').get()

通过userId（在这种情况下为电子邮件）和userPosts来组织“帖子”集合的好处是，而不是通过将userId与帖子的userId进行匹配来保持充满注释和查询的集合，就像这样：

'users':{
  'user1@gmail.com': {
    'username': 'user1'
  }
},
'posts':{
  'post1': {
     'userId': 'user1@gmail.com',
     'content': 'post1 content'
   },
  'post2': {
     'userId': 'user1@gmail.com',
     'content': 'post2 content'
   },
}

查询位置：

db.collection('posts').where('userId', '==', 'user1@gmail.com')

Answer 1

在处理nosql类型数据库时，有关数据结构的所有决策均应基于要执行的查询。在不知道您的查询的情况下，某种结构实际上可能无法满足您的应用程序的所有要求。这就是为什么数据经常在nosql数据库中重复的原因-以适应否则可能无法进行的查询。

在您的示例中，对于您提供的一个用例，以任何一种方式来构造数据都没有真正的优势。根据您可能要执行的其他查询，选择一个或另一个的优势更大。

例如，如果您想为所有用户在所有帖子中构造一些查询，那么（当前）第一个结构是不可能的。

也可能存在安全规则问题。某些数据库结构更容易通过某些安全规则进行保护。但同样，这取决于您的规则要求。

最重要的是，这种有利的结构可以满足您所有查询和规则的所有需求。但是，一个结构可能无法满足您的所有需求，并且最终可能会使两个或多个结构保持同步。

用userID作为文档关键字与使用具有userID属性的文档构造集合的好处是什么？

1 个答案: