Я создаю схему базы данных социальных сетей, в которой у меня есть пользователи, подписчики, теги и сообщения.Чтобы соответствовать модели пожарной базы, я сплющил структуру, как предложено в документации пожарной базы, как показано ниже.Проблема, с которой я сталкиваюсь, заключается в том, что когда пользователь выбирает тег и видит группу сообщений из таблицы tagPosts, все связанные с возвращаемым тегом, я хотел бы сначала показать сообщения, созданные подписчиками текущих пользователей.
В SQL это будет сделано с помощью встроенного запроса, проверяющего подписчиков пользователей по сообщениям, возвращаемым определенным тегом.Однако в Firebase я не уверен, как это сделать, не загружая все сообщения, содержащиеся в узле tagID в tagPosts, и не проверяя создателя каждого сообщения относительно узла Followers для текущего идентификатора пользователя userID.Эта операция может легко выйти из-под контроля для сотен сообщений среди сотен пользователей.Я попытался смоделировать на основе этого ответа Как проверить, существует ли значение базы данных Firebase? и эта статья От SQL к Firebase - Как структурировать БД для приложения социальной сети .Неужели я плохо структурирую данные, как мне исправить это, спасибо тебе большое.
`
Users-
-userID1
-misc. userData
-userID2
-misc. userData
Followers-
-userID1
-userIDOfFollower1
-userIDOfFollower2
Following-
-userID1
-userIDOfFollower1
-userIDOfFollower2
Posts-
-postID1
-userIDFromCreator
-misc. PostData
Tags-
-tagID1
-misc. TagData
TagsUsers
-tagID1
-userID1
-userID2
TagsPosts
-tagID1
-postID1
-postID2
Редактирование - Спасибо, Фрэнк
В нашем потоке раскадровки мы планируем иметьпользователь видит стену тегов, определяемую постоянным обновлением популярного счета на основе свойств тега и того, где, по нашим прогнозам, пользователь может быть заинтересован.Затем пользователь выберет тег и увидит сообщения, связанные с этим тегом, из тех сообщений, которые я хотел бы показать сообщения от подписчиков пользователей, прежде чем те, кто публикует сообщения, попадают в категорию указанного тега.
Я рассмотрел две возможности: либо оптимизировать чтение, в котором мне нужно будет отслеживать каждый раз, когда пользователь подписывается на тег, и записывать tagID вместе с postID в узле для каждого подписчика, которого пользователь опубликовал вспециальный узел FollowersTags, который будет иметь структуру перечисления для каждого userID списка пользователей и всех подписчиков пользователя, размещенных на нем, которые станут сотнями записей для каждого сообщения, созданного прямо пропорционально количеству подписчиков, которые есть у друга.
*creates a list of posts to a specific tag made by followers
FollowersTags
-userID1_tagID1(composite key)
-postID1
-postID2
-postID3
-postID4
-userID1_tagID2
-postID1
-postID2
-postID3
-postID4
Или я мог бы оптимизировать записи, как это было описано выше, что дает нам текущую сложность выполнения запроса в 100 с раз, прямо пропорционального количеству сообщений в теге.
Есть ли способ обойти эти два варианта, какой из двух является лучшим подходом.
К сожалению, я не смогу предсказать сообщения, отображаемые пользователю, прежде чем они выберут тег.