Альтернатива вложенным документам в Firestore - ищите лучшие практики?

Question

У меня есть некоторые опасения по поводу структуры проекта на основе Firestore, так как прямое вложение документов не представляется возможным.

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

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

В настоящее время я использую такую ​​структуру:

/app-data/match-lineup/matches/123456
/app-data/match-events/matches/123456
/app-data/match-statistics/matches/123456

И затем я обращаюсь к этому следующим образом:

      db.collection("app-data")
      .doc("match-lineups")
      .collection("matches")
      .doc(id);

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

Я бы предпочел такую ​​структуру, которая кажется мне наиболее элегантной и похожей на REST URL.

/matches/123456/lineup

Но это не вариант, поскольку 123456 не может ссылаться на документ lineup.

Обходной путь может быть что-то вроде

/matches/123456/attributes/lineup

С такой ссылкой

      db.collection("matches")
      .doc(id);
      .collection("attributes")
      .doc("lineup")

Это лучший компромисс или нетздесь другие варианты, которые стоит рассмотреть?

Answer 1

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

ИМХО, ваши два подхода полностью верны, поскольку данные, содержащиеся в каждой коллекции, будут «использоваться на отдельных экранах в приложении-потребителе» (т. Е. Нет причин «концентрировать» все данные водин документ, как вы упоминаете).С точки зрения эффективности запросов эти два подхода схожи.

Однако есть еще один критерий, который вы можете принять во внимание: (на момент написания) вы не можете запрашивать в разных коллекциях.Вы можете столкнуться с вариантом использования, когда вам нужно выполнить запрос по совпадениям, например, все совпадения с конкретным игроком в линейке или все совпадения с eventType == "penalty".В этом случае вам следует использовать подход № 1 (т. Е. /app-data/match-lineup/matches/123456), поскольку такие запросы между совпадениями будут невозможны при подходе № 2.