Лучший способ сохранить несколько коллекций под одним идентификатором пользователя

# #firebase #google-cloud-firestore

Вопрос:

Я пишу приложение, в котором не так много взаимодействий с другими пользователями. Устанавливайте и извлекайте только свои собственные данные.

В Firebase Firestore как я мог бы смоделировать это так, чтобы все соответствовало UID пользователя?

Что-то, что выглядело бы так?

 users/{uid}/user/
users/{uid}/settings/
users/{uid}/weather/
 

Если я хочу достичь чего-то подобного, то мне нужно создать еще один UID:

users/{uid}/user/{uid}/{userInfo}

Мне это кажется немного странным.

  1. Разве это неправильно? Было бы лучше, если бы я переместил каждую подборку в свою собственную коллекцию?
  2. Это быстрее / эффективнее?

Любая помощь будет признательна!

Ответ №1:

Наиболее распространенные подходы для меня:

  1. Сохраните информацию о профиле, настройках и погоде в самом документе пользователя (вашем {uid} ). Это наиболее распространено для информации профиля, но это всегда стоит учитывать и для других типов: действительно ли они должны быть в своих собственных документах?
  2. Укажите имя по умолчанию для одной вложенной коллекции для каждого пользователя, а затем укажите каждый тип информации в виде документа с известным именем. Итак /users/$uid/documents/profile , /users/$uid/documents/settings , и /users/$uid/documents/weather . Таким образом, теперь каждый тип информации находится в отдельном документе, что означает, что вы можете, например, обеспечить безопасный доступ к ним по отдельности.
  3. Если информация для определенного типа повторяется, я бы поместил ее в документы в известную/именованную подборку. Так что, если будет много погод, вы получите /users/$uid/weather/$weatherdocs . Таким образом, теперь у вас может быть бесконечный набор информации определенного типа.

Ни то, ни другое не является соответственно лучше/хуже, так как все зависит от вариантов использования вашего приложения.

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

Комментарии:

1. Спасибо за ответ, Фрэнк! Я выбираю вариант 0 (1). Я сохраню каждую категорию в ОДНОМ документе как «объект объектов». { weather: {}, settings: {} } потому что не будет случая использования, когда они будут запрашиваться независимо.