Структура данных Firebase — поддержание дублированных данных в актуальном состоянии

#firebase #firebase-realtime-database

#firebase #firebase-база данных в реальном времени

Вопрос:

Я создал плоскую структуру данных. При отправке дублированных данных, каков принятый шаблон для поддержания этих данных в актуальном состоянии. Здесь данные для информации о группах дублируются в users-groups и groups дереве.

 {
 "users": ..
 "users-groups": ..
 "groups": ..
}
  

При создании группы для пользователя происходит два обновления:

Сначала: нажмите на /groups / group_key

 {
 "name": "Test Group",
 "image: "/testimage.jpg"
}
  

Второй: нажмите на / users-groups /user_uid/group_key

 {
 "orderNum: 0,
 "info": {
  "name": "Test Group",
  "image: "/testimage.jpg"
 }
}
  

Должно ли поддержание этих данных в группах пользователей в актуальном состоянии быть задачей клиента или сервер должен справиться с этим?

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

Есть ли какие-либо руководства или справочные материалы по этой проблеме?

примечание: я использую эту структуру, потому что пользователь может быть членом нескольких групп, и я не думаю, что было бы хорошей идеей сделать, возможно, несколько ref.once , чтобы получить данные из /groups/ напрямую.

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

1. что? это? Передача данных с использованием адаптеров синхронизации

2. Нет, я не говорю о структуре данных, ничего специфичного для Android

3. Я думаю, вы можете искать это: firebase.googleblog.com/2015/10/client-side-fan-out-for-data-consistency_73.html

4. Спасибо, чувак, это именно так

Ответ №1:

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

 db.ref("").update({
  '/users/dedd': info,
  '/users/cdcd': info2
})
  

Ответ №2:

У вас не должно быть сохраненных дублированных данных. Вместо этого вы должны сохранить ссылку на group.

Ваши данные должны выглядеть следующим образом.

 {
    "users": {
        "userkey1": {
            "data": {
                "name": "",
                "firstname": ""
            },
            "groups": {
                "groupkey1": true // true or orderNum value
            }
        }
    },
    "groups": {
        "groupkey1": {
            "data": {
                "name": "Test Group",
                "image": "/testimage.jpg",
                "other": "data"
            },
            "users": {
                "userkey1": true
            }
        }
    }
}
  

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

users/userkey1/groups/groupkey1 или groups/groupkey1/users/userkey1 .

Когда вы создаете новую группу, вы сохраняете под groups/newgroupkey позицией и обновляете groups под users узлом, установив только newgroupkey значение true . Таким образом, вы не дублируете свои данные.

Для получения дополнительной информации о структурировании ваших данных перейдите по следующей ссылке.

https://firebase.google.com/docs/database/android/structure-data

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

1. Да, это то, к чему я стремлюсь, хотя я также использую дублирование данных. Почему бы не использовать дублированные данные? Это избавляет меня от необходимости создавать прослушиватели для всех «объединений»? Дублирование данных является общепринятым шаблоном в NOSQL, верно?

2. Например, если я хочу получить список групп пользователей, мне нужно инициализировать прослушиватель для коллекции users-groups, а затем один или несколько для каждого, чтобы связать с фактической информацией о группе.

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

4. Да, я знаю, что я обсуждаю, просто для этого небольшого примера я собираюсь представить два вентилятора данных, которые необходимо поддерживать. То, как я воспринимаю сообщение в блоге, на которое ссылается Фрэнк ван Пуффелен, таково: NOSQL отлично справляется с этим. В моем случае я думаю, что это будет связано с тем, что я могу ограничить количество групп, которые может иметь пользователь, и количество пользователей, которые может иметь группа, поэтому я не думаю, что это будет проблемой для меня.

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