Выполните запрос JOIN в облачном магазине Google. - PullRequest
0 голосов
/ 19 июня 2019
{  
   "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).

Как добиться этого в запросе в fire-storeв узле?

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

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

Я надеюсь, что этого легко достичь с помощью запроса SQL "JOIN"

Как выполнить этот запрос реализации в fire-store на узле?

1 Ответ

0 голосов
/ 19 июня 2019

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...