Документ против коллекции - PullRequest
0 голосов
/ 19 июня 2019

Я борюсь с Firestore.Вопрос в том, как структурировать данные, не сталкиваясь с ловушкой / кошмаром.

У меня следующая структура данных:

school
  course1
    section1
      page1
      page2
    section2
      page1
      page2
    ...

Я предполагаю, что курс обычно не имеет более 50разделы.

Использовать коллекцию

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

db.collection("schools")
.document("school1")
.collection("courses")
.document("course1")
.collection("sections").snapshots()

Структура документа:

name: "Section 1"
description: "Description 1"

Однако, если мне нужно отобразить список разделов, то в соответствии с биллингом Firestore я получу плату за каждое чтение документа.Это означает, что если есть 20 разделов, я получу плату за 20 чтений.

Использование документа с вложенными коллекциями

Я также мог бы просто создать документ "Курс 1"и вложите все разделы.

db.collection("schools")
.document("school1")
.collection("courses")
.document("course1")
.get()

Структура документа:

name: "Course 1"
description: "The description",
sections: [
  {
    name: "Section 1", 
    description: "Description 1"
    pages: [
      {name: "Page 1", description: "Page Description 1"},
      {name: "Page 2", description: "Page Description 2"}
    ]
  },
  {
    name: "Section 2", 
    description: "Description 2"},
    pages: [
      {name: "Page 1", description: "Page Description 1"},
      {name: "Page 2", description: "Page Description 2"}
    ]
  ...
]

Тогда я получу плату только за 1 чтение.Скорее всего, я бы не столкнулся с лимитом в 40 000 атрибутов, а также с лимитом в 1 МБ.

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

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

Какой вариант лучше?

1 Ответ

1 голос
/ 20 июня 2019

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

Когда использовать вложенные коллекции:

1) Если вы не хотите хранить много полей в документе. Облачный Firestore имеет ограничение в 20 000 полей. (Если информация о школах и курсах может превышать 20 000 полей)

2) При обновлении родительской коллекции это обычная операция. Firestore позволяет обновлять документ только со скоростью 1 запись в секунду. (Если информация о школах, курсах и страницах изменяется очень часто)

3) Если вы хотите ограничить доступ к определенным полям документа. (Если вы хотите ограничить доступ к страницам курса. В этом случае перенос ограниченных полей в другой документ в другой коллекции также является хорошей идеей!)

Когда не использовать вложенные коллекции:

1) Когда вы хотите запросить коллекции и вложенные коллекции вместе. Запросы Firestore мелкие. Таким образом, подзапросы не будут запрашиваться при запросе родительской коллекции, поэтому вам придется запрашивать их отдельно. (Если у вас есть случай, чтобы показать все школы и их курсы в одном окне)

2) Когда вы хотите показать вложенную коллекцию при просмотре коллекции. (При отображении школы вы можете показать ее курсы. Здесь число чтений будет увеличиваться, поскольку вместо чтения одного документа вы читаете один документ и его подколлекция все время)

3) Когда вы хотите запросить коллекции и вложенные коллекции вместе (вы должны использовать запрос группы коллекций, поскольку вложенные коллекции по сути являются коллекциями.)

4) Если вы думаете о запросе отдельных фрагментов данных, вы должны поместить их в коллекцию. (Если конкретные атрибуты Школы обычно запрашиваются пользователями, или детали курса просматриваются несколькими пользователями)

Мое предложение:

Schools
  - Array<CourseIds>
  - Other info

Schools коллекция для хранения школьной информации, по которой можно искать школы по их качествам. Информация о школах также может содержать поле courses_available, которое может быть массивом или картой для хранения только названия курса и его unique id.

Courses
  -Course info

Courses коллекция с тем же подходом, так как я предполагаю, что информация о курсе будет запрашиваться много в соответствии с их атрибутами.

CourseSections
  -Course1Section1
    -Pages
  -Course1Section2
    -Pages

CourseSections сборник для информации о разделах курса, который имеет подколлекцию Pages.

Преимущества:

  1. Это поможет вам добавить много страниц в каждый раздел.
  2. CourseSection может быть прочитано по требованию, поэтому вам не нужно читать все его разделы при чтении Course.

В конечном счете, выбор зависит от ваших вариантов использования.

Надеюсь, это поможет.

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