Есть ли способ сделать меньше запросов в firebase?

Question

на самом деле моя коллекция firestore выглядит так:

user :
    |-> 0000 (uid)
        |-> avatar : 'url'
        |-> name : 'josh'
    |-> 1111
        |-> avatar : 'url'
        |-> name : 'steve'
    [...]

follow :
    |-> 0000
        |-> 1111 : true
        |-> 8888 : true
    [...]

message :
    |-> 0000
        |-> 8888
            |-> 1264978800 (timestamp)
                |-> message = "hello"
            |-> 1264978987 
                |-> message = "How are you"
    |-> 8888
        |-> 0000
            |-> 1264914253
                |-> message = "hey dude "
            |-> 1264975895 
                |-> message = "fine and you?"

Если я хочу получить профиль и диалог между 0000 и 8888 (например, чтобы получить аватар), мне нужно:

1. проверить, есть ли у их друга
2. , если да, получить сообщения 0000
3. получить сообщения 8888
4. получить профиль 0000
5. получить 8888 profile

Если мне нужен список всех разговоров 0000, мне нужно сделать:

1. проверить всех пользователей, чтобы узнать, дружат ли они
2. для каждого друга получить профиль
3. для каждого друга получить список сообщений.

Это очень простые запросы, и они кажутся более сложными, чем, например, mysql.

Есть способ не выполнять все эти запросы? Мой шаблон базы данных хорош?

Спасибо за помощь.

Answer 1

Пора подумать Нет SQL с Firebase. Firestore - это база данных в реальном времени, где важна производительность. Ваша структура данных подходит для базы данных SQL, а не для No SQL.

Ниже представлена ​​структура данных, которую я предлагаю для этого варианта использования:

user :
    |-> 0000 :    //uid
        |-> id : '0000'
        |-> avatar : 'url'
        |-> name : 'josh'
        |-> follow : ['1111', '8888']    // Array of uid
    |-> 1111 :     //uid
        |-> id : '1111'
        |-> avatar : 'url'
        |-> name : 'steve'
        |-> follow : ['0000']    // Array of uid
    [...]

message :
    |-> AAAA    // message id
        |-> id : 'AAAA'
        |-> sender
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> receiver
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> time : 1264978800    // timestamp
        |-> message : "hello"
    |-> BBBB    // message id
        |-> id : 'BBBB'
        |-> sender
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> receiver
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> time : 1264978800    // timestamp
        |-> message : "hey dude"
    |-> CCCC    // message id
        |-> id : 'CCCC'
        |-> sender
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> receiver
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> time : 1264978800    // timestamp
        |-> message : "How are you"
    |-> DDDD    // message id
        |-> id : 'DDDD'
        |-> sender
            |-> id: '8888'
            |-> avatar: 'url'
            |-> name: 'paul'
        |-> receiver
            |-> id: '0000'
            |-> avatar: 'url'
            |-> name: 'josh'
        |-> time : 1264978800    // timestamp
        |-> message : "fine and you?"

Вышеуказанная структура спроектирован способом № SQL. Профили пользователей дублируются несколько раз. Существует дублирование данных для повышения производительности и снижения пропускной способности и затрат ЦП, что намного дороже, чем хранение.

Преимущества:

• Каждый пользователь содержит всю информацию о пользователе
• Каждое сообщение содержит всю информацию о сообщении

Теперь давайте рассмотрим ваши варианты использования:

Если я хочу получить профиль и беседу между 0000 и 8888 (чтобы получить аватар, например), мне нужно:

1. проверить, если их друг
2. , если да, получить сообщения 0000
3. получить сообщения 8888
4. получить профиль 0000
5. получить профиль 8888

запрос message где sender или receiver находится в follow.

Если мне нужен список всех разговоров 0000, мне нужно сделать:

1. проверить всех пользователей, чтобы узнать, являются ли они друзьями
2. для каждого друга, получить профиль
3. для каждого друга, получить список сообщений.

Запрос message где sender или * 1 056 * равно '0000'

Другие варианты использования, которые могут возникнуть у вас:

• Список друзей с именем и аватаром, которые будут перечислены.

Вы можете использовать массив карты для follow для хранения uid, name и avatar или даже сделать подписку в качестве подколлекции, если вы собираетесь выполнять с ней несколько операций.

• Пользователь меняет имя или аватар.

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

Сказав все это, очевидно, что ваш выбор - использовать SQL или Нет SQL. У обоих есть свои достоинства и недостатки