#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. Я упомянул сервер, потому что в худшем случае я мог бы поставить на него задачи по распределению задач по очереди или что-то в этом роде, где каждому клиенту не нужно поддерживать разветвления с тысячами зависимостей.