Как разработать схему базы данных Cloud Firestore

Для перехода с базы данных реального времени на облачное хранилище требуется полная переработка базы данных. Для этого я создал пример с некоторыми основными дизайнерскими решениями. См. изображение и дизайн базы данных в электронной таблице ниже. Мои два вопроса:

1 - когда у меня есть отношение «один ко многим», можно ли также хранить информацию в виде массива в документе? См. строку 8 в дизайне базы данных.

2 - Должен ли я включать только ссылку или дублировать всю информацию в отношении «один ко многим». См. строку 38 в модели базы данных.

введите описание изображения здесь

https://docs.google.com/spreadsheets/d/13KtzSwR67-6TQ3V9X73HGsI2EQDG9FA8WMN9CCHKq48/edit?usp=sharing


person Hans Anker    schedule 02.11.2017    source источник


Ответы (2)


Для вопроса 1 в документации firestore есть решение: https://cloud.google.com/firestore/docs/solutions/arrays

вместо использования массива вы используете карту значений и устанавливаете для них значение «true», что позволяет вам запрашивать их, например:

teachers: {
        "teacherid1": true,
        "teacherid2": true,
        "teacherid3": true
    }

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

person Mark Kvetny    schedule 02.11.2017

В общем: держите хранилище данных как можно более мелким, т. е. избегайте вложенных коллекций и вложенности.

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

Что касается модели данных Firestore, всегда учитывайте Как я буду запрашивать это хранилище данных?. Используйте вложенные коллекции, массивы и карты экономно (редко) и только в случае необходимости (и, скорее всего, вам это не нужно). Используйте автоматический идентификатор против удобочитаемого идентификатора, например. используйте 000kztLDGafF4uKb8Cal вместо banana для идентификаторов документов.

По мере увеличения функциональности приложения сценарии на стороне сервера с помощью Cloud Functions for Firebase и/или Admin SDK становятся бесценным инструментом для управления (создания и индексирования) отношениями данных «многие ко многим». Например, полнотекстовый поиск не поддерживается в Firestore. Это сводится к тому, что кажется препятствием для реализации надежных функций поиска в вашем приложении.

В заключение старайтесь избегать вложенных коллекций, вложений, массивов и карт. Следуйте принципу «будь проще, глупее», KISS. Как только ваше приложение масштабируется и/или требует дополнительных функций, можно использовать сценарии на стороне сервера, чтобы ваше приложение оставалось отзывчивым (быстрым), предлагая при этом надежные функции.

person Ronnie Royston    schedule 12.03.2019
comment
держите хранилище данных как можно более мелким - мне интересно, есть ли у вас какие-либо ссылки, чтобы раскрыть эту точку? - person vir us; 05.05.2019
comment
только опыт. Индексация (на стороне сервера или в облаке/предварительная фильтрация) позволяет создавать виртуальные таблицы — по крайней мере, так можно думать об этом. Я буквально загрузил 1,5 миллиона документов в одну коллекцию, и как только мои основные типы запросов проиндексированы, она работает так же быстро/отзывчиво, как если бы я создал специальную коллекцию. Неглубокое хранилище данных означает более простое кодирование. В 9 случаях из 10 вам не нужна еще одна коллекция. Принцип KISS. - person Ronnie Royston; 05.05.2019
comment
Спасибо, Рон. Это имеет большой смысл. Быстрый вопрос: какие самые большие недостатки вы можете увидеть с этим подходом? Также я предполагаю, что у вас есть что-то вроде поля типа в каждом документе для поддержки этого подхода к виртуальной таблице, чтобы вы могли использовать его для извлечения документов, принадлежащих одной и той же таблице, это правильно? Спасибо еще раз! - person vir us; 05.05.2019
comment
правильно, я использую type и category или что-то еще. Мои коллекции верхнего уровня — это users, locations, ratings и т. д. Я установил для них свойство owner, чтобы включить авторизацию/безопасность с помощью правил безопасности. - person Ronnie Royston; 06.05.2019