Предпочтение структуры базы данных

Question

У меня есть структура данных на основе документов, заполненная пользователями.Информация о пользователях будет включать в себя еженедельную повестку дня (действия, которые необходимо выполнить в течение одной недели, например: прогон 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

Answer 1

Не существует "идеального", "лучшего" или "правильного" решения для структурирования базы данных Cloud Firestore.

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

В отличие от базы данных реального времени 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);
  

  Этот запрос также может быть написан на других языках программирования.

Answer 2

(для дальнейшего использования этот тип вопроса "передового опыта" лучше подходит для группы Google Firebase , чем для переполнения стека)

Во-первых, я не уверен, было ли это преднамеренным или ошибочным в вашей диаграмме, но я просто хочу отметить, что в Структуре # 1 вы должны иметь username, age и gender как поля в пользовательском документе, а не в качестве подколлекции, как показано на диаграмме. (Я предполагаю, что это то, что вы имели в виду, учитывая ваше описание, но просто чтобы быть уверенным, поскольку пользовательские данные будут плохо использовать вложенные коллекции).

Теперь на ваш главный вопрос:

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

То, как вы структурируете свои данные, зависит от того, как вы планируете взаимодействовать с ними , а не только от того, как имеет смысл смотреть.

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