С недавним введением запросов на подгруппы для групп, мне любопытно, смогу ли я задать этот вопрос схемы для социальной платформы с подписчиками и постами.
Как заявление об отказе от ответственности, я полностью согласен с идеей дублирования данных с использованием облачных функций для их синхронизации и т. Д.
Первая из двух основанных на подписчиках (простой пользователь A следует за B, и время от времени требуется извлекать все сообщения от всех подписчиков):
Выполняйте поиск только тех пользователей, которых вы интересуете, чтобы увидеть подписчиков / подписчиков, и они будут коллекциями в документе с их именем.
Пользователь A следует за пользователем B:
Получить все пользовательские подписки =
Получить подколлекцию для пользователя A
Получить всех пользователей А последователей =
Получить подписчиков вложенной коллекции для пользователя A (там будет пользователь B)
Follows (C)
---> UID (D)
---> Followers (C)
---> UIDB (D)
---> UIDE (D)
---> Following (C)
---> UIDF (D)
---> UIDG (D)
---> UID (D)
---> Followers (C)
---> UIDB (D)
---> UIDE (D)
---> Following (C)
---> UIDF (D)
---> UIDG (D)
Поиск всех коллекций, названных ** После , где существует пользователь **
Пользователь A следует за пользователем B:
Под пользователем А я нахожу пользователя B
Преимущество: хранить только следующее
Недостаток: переберите все вложенные коллекции, чтобы получить данные
Users (Coll)
---> UID (Doc)
---> Following (C)
---> UIDB (D)
---> UIDC (D)
---> UID (D)
---> Following (C)
---> UIDB (D)
---> UIDE (D)
Запросы вложенных коллекций позволяют выполнять запросы в любом месте, где есть собрание с документом с таким именем, поэтому, если я ищу: Все пользователи, в которых «Подписка» содержит UIDB, я должен вернуть только соответствующие документы.
Оба кажутся логичными и делают то, что нужно, мне любопытно, может ли любой из них лучше для любой причина