Выполните запрос JOIN в облачном хранилище google firestore

{  
   "users":{  
      "userid_1":{  
         "following":{  
            "userid_2":{  
               "name":"user2"
            },
            "userid_3":{  
               "name":"user3"
            }
         }
      },
      "posts":{  
         "postid1":{  
            "createdTime":"111",
            "postedBy":"userid_2"
         },
         "postid2":{  
            "createdTime":"112",
            "postedBy":"userid_3"
         },
         "postid3":{  
            "createdTime":"113",
            "postedBy":"userid_2"
         },
         "postid4":{  
            "createdTime":"114",
            "postedBy":"userid_1"
         }
      }
   }
}

Я хочу получить сообщения следующих пользователей «userid_1», отсортированные по времени создания с ограничением 2 (2 сообщения на вызов API).

Как выполнить запрос в хранилище огня в узле?

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

Если у пользователя есть 1000 подписчиков, а у 1000 человек есть 100 сообщений, то нельзя получать все последующие сообщения пользователя и сортировать их по времени создания.

Я надеюсь, что мы сможем легко добиться этого с помощью SQL-запроса «JOIN».

Как выполнить этот запрос реализации в магазине огня на узле?

sql node.js firebase google-cloud-firestore

19.06.2019 08:37

ReactJs | Supabase | Добавление данных в базу данных

Это и есть ваш редактор таблиц в supabase.👇

Понимание Python и переход к SQL

Перед нами лабораторная работа по BloodOath:

3 824

Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

В Firestore нет концепции JOIN на стороне сервера. Все документы в одной операции чтения должны поступать из одной коллекции.

Это означает, что для получения данных из нескольких коллекций вам потребуется выполнить несколько операций чтения — как минимум по одной на коллекцию, но возможно и больше. Это нормально для большинства баз данных NoSQL и не так медленно, как думают многие разработчики, учитывая тот объем данных, который вы должны считывать из клиентского приложения.

Если количество документов, которые вам нужно прочитать, слишком велико для вашего приложения, рассмотрите возможность изменения модели данных, чтобы требовать меньше операций чтения. Как правило, это означает, что вы в конечном итоге дублируете некоторые данные в формате, более удобном для чтения.

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

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

Эта тема невероятно широка, и ее трудно отдать должное в одном ответе, поэтому я рекомендую вам также: