Предпочтение структуры базы данных
У меня есть структура данных на основе документов, заполненная пользователями. Информация о пользователях будет включать еженедельную повестку дня (действия, которые нужно выполнить в течение одной недели, например: пробежать 10 минут в понедельник, пойти по магазинам во вторник) и другую важную информацию, такую как их имя, пол, возраст и т. д. Пользователи могут иметь несколько недельных повесток дня (например, одну на эту неделю, другую на следующую неделю и т. д.)
Однако я не знаю, как структурировать эти данные.
Если в каталоге пользователя есть два подкаталога, один с именем «weekly_agendas» (содержащий документы всех недельных повесток дня пользователя), а другой с именем «user_data», содержащий личную информацию, такую как имя, пол, возраст и т. д. По сути, вложенность данные создаются.
ИЛИ:
Следует ли переместить каталог weekly_agendas за пределы каталога пользователей?
Я везде гуглил, и все документы обычно предлагают предотвратить вложенную структуру данных, но как эта вложенная структура данных может быть плохой?
Это может помочь проиллюстрировать, чего я пытаюсь достичь:
Structure #1
users
|
+--user_id
|
+--user_data
|
+--username
+--age
+--gender
+--weekly_agenda
|
+--weekly_agenda_number
|
+--1: walk the dog on Monday
+--2: Go shopping on Tuesday
Structure #2:
users
|
+--user_id
|
+--username
+--age
+--gender
+--weekly_agenda
|
+--user_id
|
+--weekly_agenda_number
|
+--1: walk the dog on Monday
+--2: Go shopping on Tuesday
Ответы 2
(для справки в будущем этот тип вопросов "передовой практики" лучше подходит для Группа Google Firebase, чем Stack Overflow)
Во-первых, я не уверен, было ли это намеренно или ошибкой на вашей диаграмме, но я просто хочу указать, что в структуре № 1 у вас должны быть поля username, age и gender как поля в пользовательском документе, а не как подколлекция, как показано на диаграмме. (Я предполагаю, что это то, что вы имели в виду, учитывая ваше описание, но на всякий случай, поскольку пользовательские данные будут плохо использовать подколлекции).
Теперь к вашему основному вопросу:
Firestore значительно выигрывает при работе со структурой данных плоский, то есть со структурой с большим количеством небольших документов, в отличие от небольшого количества больших документов. Это один из моментов, на который ссылаются, когда говорят о методах борьбы с гнездованием.
То, как вы структурируете свои данные, зависит именно от как вы планируете с ним взаимодействовать, а не только от того, на что имеет смысл смотреть.
Structure #1 не будет работать так же хорошо, как Structure #2, если вы когда-нибудь планируете, что пользователь сможет видеть программы других пользователей. Он по-прежнему будет работать, но запрос будет намного уродливее.
При этом, если повестки дня видны только их владельцам, то Structure #1 может иметь больше смысла, просто учитывая тот факт, что организация более интуитивно понятна для этой цели. Вы также можете испытать немного более быстрое время ответа на запрос, используя Structure #1.
В Structure #2 нет ничего плохого. Если сейчас или в будущем пользователи смогут просматривать программы других пользователей, то Structure #2 - ваш лучший выбор. Structure #2 также лучше, если вы планируете искать повестки дня для нескольких пользователей на основе одного из его полей. Например, если вы когда-либо хотели найти 20 самых последних документов повестки дня приложения по их полю timestamp.
В моем проекте очень похожая ситуация, но в другом контексте. В нашем приложении есть Posts и Content. Каждый Post содержит один или несколько Content. Мы могли бы сделать Content вложенной коллекцией на каждом Post (например, ваш Structure #1), но вместо этого мы сделали Content коллекцией корневого уровня (например, ваш Structure #2), потому что нам нужно было запрашивать документы Content среди пользователей на основе одного из их полей.
В заключение, Structure #2 более гибкий, но если вы уверены, что не хотите запрашивать повестки дня нескольких пользователей (запрос группы сбора), то Structure #1 может быть более выгодным.
Обычно я по умолчанию использую Structure #2, за исключением тех редких, но законных обстоятельств, когда действительно имеет смысл изолировать данные в определенных документах.
Не существует «идеального», «лучшего» или "правильный" решения для структурирования базы данных Cloud Firestore.
I have googled everywhere, and all documents typically suggest preventing nested data structure, but how could this nested data structure be bad?
В отличие от базы данных реального времени Firebase, где отображается список еженедельных повесток дня, вы бы загрузили весь пользовательский объект, в Cloud Firestore это больше не проблема. Так что вложение подколлекции с именем weekly_agenda под каждый пользовательский документ не будет проблемой. Обратной стороной первого подхода является то, что вы не можете запрашивать свою базу данных для отображения всех повесток дня всех пользователей. Итак, возможная схема, представляющая собой сочетание вашего решения, может быть:
Firestore-root
|
--- users (collection)
| |
| --- uid (document)
| |
| --- username: "John"
| |
| --- age: 22
| |
| --- gender: "male"
|
--- weeklyAgenda (collection)
|
--- weeklyAgendaId (document)
|
--- uid: "UidOfTheUser"
|
--- //Weekly Agenda Properties
Используя эту схему, вы можете просто:
- Запросите всех пользователей из всей вашей базы данных, подключив слушателя к коллекции
users. - Запрашивайте повестки дня всех пользователей, прикрепив слушателя к коллекции
weeklyAgenda. Запросите все повестки дня, принадлежащие одному пользователю, с помощью запроса, который в Android может выглядеть следующим образом:
FirebaseFirestore rootRef = FirebaseFirestore.getInstance(); Query query = productsRef.whereEqualTo("uid", uid);Этот запрос также можно написать на других языках программирования.