2016-10-22 4 views
0

DATABASE ИЕРАРХИЯ:Как правильно запросить все сообщения, созданные пользователем?

posts 
    post1_uid 
     author: user2UID 
     info1 
     info2 
    post2_uid 
     author: user1UID 
     info1 
     info2 
users 
    user1_UID 
     info1 
     info2 
     info3 
    user2_UID 
     info1 
     info2 
     info3 

СИТУАЦИЯ:

Пользователь может создавать сообщения. Каждое сообщение имеет свойство «автор», которое содержит UID пользователя, создавшего сообщение.

Если я хочу, чтобы показать все сообщения от одного пользователя, я пишу в своем Firebase GET запроса:


КОД:

if (childData.author == firebase().auth().currentUser.uid) { 
    //Show those posts created by the current user 
} 

ВОПРОС

Будет ли это эффективным nt, если в моей базе данных Firebase есть миллионы сообщений, а идентификатор текущего пользователя нужно сравнить с свойством «автор» каждого сообщения?

Если нет, есть ли лучший вариант?


ЧТО Я ПРОБОВАЛИ:

Создание в моем «пользователи/UID /» путь к «сообщений» узел, который содержит идентификаторы всех сообщений, которые создали пользователь.

Таким образом, я перебираю гораздо меньшее дерево json (только все сообщения, созданные пользователем (100)) по сравнению с итерированием всех сообщений в базе данных (миллионы), чтобы найти тех, кто был создан пользователь. Но действительно ли это влияет на производительность? Стоит ли увеличить вложенность данных?


ДРУГИЕ БАЗЫ ИЕРАРХИЯ:

posts 
    post1_uid 
     author: user1UID 
     info1 
     info2 
    post2_uid 
     author: user1UID 
     info1 
     info2 
users 
    user1_UID 
     info1 
     info2 
     info3 
     posts 
     referenceUID 
      post1UID 
      post2UID  
    user2_UID 
     info1 
     info2 
     info3 

Вот фактическая база данных иерархии с некоторыми фальшивыми данными, чтобы имитировать поведение моего примера.

enter image description here


TL; DR:

Как правильно организовать Firebase базы данных для оптимизации запросов в поисках всех сообщений, созданных пользователем?

ответ

2

Ответ будет неполно вложенным почтовым данным внутри каждого пользователя.

Вот основная проблема с производительностью при фильтрации из всего узла сообщений. Прежде всего, чтобы отфильтровать сообщения вашего текущего пользователя, вы должны запустить запрос вроде этого postsRef.orderByChild('author').equalTo(currentUser.uid), как вы заметили orderByChild - это дорогостоящая операция, даже если вы используете индекс на author, это было бы дорого для миллионов записей.

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

Смежные вопросы