Есть ли какие-либо преимущества использования вложенных коллекций в пожарном депо?

Question

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

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

Это заставляет меня задаться вопросом, в чем вообще смысл подколлекций, если вы можете просто связать эти документы с идентификатором. Это только для того, чтобы вы могли расширить, если ваш документ становится ближе к пределу в 1 МБ?

Answer 1

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

Firestore-root
    |
    --- questions (collections)
          |
          --- questionId (document)
                 |
                 --- questionId: "LongQuestionIdOne"
                 |
                 --- title: "Question Title"
                 |
                 --- tags (collections)
                      |
                      --- tagIdOne (document)
                      |     |
                      |     --- tagId: "yR8iLzdBdylFkSzg1k4K"
                      |     |
                      |     --- tagName: "History"
                      |     |
                      |     --- //Other tag properties
                      |
                      --- tagIdTwo (document)
                            |
                            --- tagId: "tUjKPoq2dylFkSzg9cFg"
                            |
                            --- tagName: "Geography"
                            |
                            --- //Other tag properties

, в котором tags - это подколлекция в questionId объекте. Давайте теперь создадим коллекцию tags как коллекцию верхнего уровня, например:

Firestore-root
    |
    --- questions (collections)
    |     |
    |     --- questionId (document)
    |            |
    |            --- questionId: "LongQuestionIdOne"
    |            |
    |            --- title: "Question Title"
    |
    --- tags (collections)
          |
          --- tagIdOne (document)
          |     |
          |     --- tagId: "yR8iLzdBdylFkSzg1k4K"
          |     |
          |     --- tagName: "History"
          |     |
          |     --- questionId: "LongQuestionIdOne"
          |     |
          |     --- //Other tag properties
          |
          --- tagIdTwo (document)
                |
                --- tagId: "tUjKPoq2dylFkSzg9cFg"
                |
                --- tagName: "Geography"
                |
                --- questionId: "LongQuestionIdTwo"
                |
                --- //Other tag properties

Различия между этими двумя подходами:

• Если вы хотите выполнить запрос к базе данных, чтобы получить все tags определенного вопроса, с помощью первой схемы это очень просто, потому что требуется только CollectionReference (questions -> questionId -> tags). Чтобы добиться того же, используя вторую схему, вместо CollectionReference, необходим Query, что означает, что вам нужно запросить всю коллекцию tags, чтобы получить только теги, которые соответствуют одному вопросу.
• При использовании первой схемы все более организовано. Кроме того, в Firestore Максимальная глубина вложенных коллекций: 100 . Таким образом, вы можете воспользоваться этим.
• Как и @RenaudTarnec, упомянутый в его комментарии, запросы в Cloud Firestore мелкие, они получают только документы из коллекции, с которой выполняется запрос. Невозможно получить документы из коллекции верхнего уровня и других коллекций или вложенных коллекций в одном запросе. Firestore не поддерживает запросы к различным коллекциям за один раз. Один запрос может использовать свойства документов только в одной коллекции. Таким образом, вы не сможете получить все теги всех вопросов, используя первую схему.

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

Это только для того, чтобы вы могли расширяться, если ваш документ становится ближе к пределу в 1 МБ?

Если у вас есть вложенная коллекция объектов в документе, обратите внимание, что размер вложенной коллекции не учитывается в этом пределе 1 МБ. Учитываются только те данные, которые хранятся в свойствах документа.