В чем преимущество структурирования коллекций с userID в качестве ключей документа по сравнению с документами с атрибутом userID?

Question

Специально для Firestore, почему бы структурировать свои корневые коллекции как документы userId, которые содержат подколлекцию userPosts, которая содержит сообщения каждого пользователя.Почему бы просто не хранить записи в корневой коллекции и фильтре запросов по идентификатору пользователя?

Например, многие StackOverflow Q / As относительно структурирования данных предлагают иметь что-то вроде этого:

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

, где 'users' и 'posts' - это коллекции, а 'userPosts' - это sub.-collection и запрос:

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 - для удовлетворения запросов, которые в противном случае могут быть невозможны.

В вашем примере для предоставленного вами одного варианта использования естьнет никакого реального преимущества структурирования данных в любом случае.Преимущество выбора одного или другого с большей вероятностью основано на других запросах, которые вы, возможно, захотите выполнить.

Например, если вы хотите построить какой-либо запрос по всем сообщениям для всех пользователей, это (в настоящее время)невозможно с вашей первой структурой.

Может также быть проблема правил безопасности.Некоторые структуры баз данных легче защитить с помощью некоторых правил безопасности.Но опять же, это зависит от требований к вашим правилам.

Суть в том, что выгодная структура - это та, которая отвечает всем потребностям всех ваших запросов и правил.Но одна структура может не соответствовать всем вашим потребностям, и в итоге вы можете синхронизировать две или более.