Не существует единой правильной модели данных, так как (со всеми решениями NoSQL) лучшая модель данных зависит от вариантов использования вашего приложения.
Но, насколько я понимаю, у вас есть два основных варианта:
- Гнездо детской коллекции
- Подключение документов путем встраивания родительских идентификаторов
Гнездо детской коллекции
Firestore - это база данных, которая содержит коллекции документов. Каждый документ может содержать подколлекции под ним. Учитывая, что ваша модель данных является иерархической, это означает, что вы можете вкладывать их следующим образом:
Tournaments (collection)
Tournament1 (document)
Tours (collection)
Tour1_1 (document)
Notes (collection)
Notes1_1_1 (document)
Теперь у каждого турнира есть свои туры, и у каждого тура есть свои заметки. Вы можете получить к ним доступ по отдельности: просто прочитайте заметки для одного тура, без необходимости создавать запрос для этого.
Подключение документов путем встраивания родительских идентификаторов
Альтернативой является создание трех коллекций верхнего уровня и подключение каждого дочернего документа к его родительскому элементу путем встраивания в него родительского идентификатора, например:
Tournaments (collection)
Tournament1 (document)
Tours (collection)
Tour1_1 (document)
TournamentID: Tournament1
Notes (collection)
Notes1_1_1 (document)
TourID: Tour1_1
С этой моделью вы можете получить все Туры на Турнир, запросив ref.collection("Tours").where("TournamentID", "==", "Tournament1")
.
Преимущество второй модели состоит в том, что вы можете получить доступ к турам по всем турнирам, тогда как в первой модели вы можете получить доступ к турам только для одного турнира за раз (по крайней мере, пока Firestore не выполнит запросы групп сбора).
Недостатком второй модели является то, что вам всегда нужно запрашивать, и что она менее масштабируема в отношении записи.