Различные коллекции для каждого типа пользователей в корне Firestore - PullRequest
0 голосов
/ 11 сентября 2018

Я создаю приложение на основе Cloud Firestore.Приложения работают как-то так же, как Uber.Так что проблема в том, что я довольно новичок в базах данных NoSQL, у меня проблемы с созданием хорошей структуры базы данных.Вот LINK к UML, который я планировал использовать для своего приложения для Android.Я планирую использовать Firestore для хранения информации о пользователях и других данных, тогда как база данных в реальном времени будет использоваться для обновления карт в реальном времени.

Моя главная проблема здесь, как вы можете видеть в UML,это как-то показывает отношения между различными таблицами, но NoSQL не имеет таблиц и отношений, что доставляет мне затруднения.Приблизительно после 4 часов непрерывного поиска в Интернете об этом я все еще не уверен, что сделать.У меня есть несколько вопросов, на которые я хотел бы получить ответ:

1) Можно ли каким-либо образом создать отношения между различными коллекциями?

2) Должен ли я сохранять все 3 типа пользователей в одной коллекции «пользователь» или создавать разные коллекции для каждого типа в корне.Каковы будут последствия использования обоих подходов.

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

3) Сколько изглубокое вложение, которое мне разрешено делать в одной коллекции, т.е. в подколлекциях в коллекциях?

4) Правильно ли мое решение использовать 2 разные базы данных в одних и тех же приложениях?

5) Является ли Firebase правильным выбором для приложения, которое я создаю?

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

1 Ответ

0 голосов
/ 11 сентября 2018

1) Можно ли как-нибудь создать отношения между разными коллекциями?

Да, есть.Вы можете создавать отношения между различными коллекциями, удерживая ссылки, как указано в официальной документации, относительно поддерживаемых типов данных .Например:

projects/[PROJECT_ID]/databases/[DATABASE_ID]/documents/[DOCUMENT_PATH].

Существует также другой обходной путь, который включает duplicating data, и для этого я рекомендую посмотреть это видео, Денормализация нормальная с базой данных Firebase .Предназначено для базы данных реального времени Firebase, но те же принципы применимы к Cloud Firestore.

2) Должен ли я сохранять все 3 типа пользователей в одной коллекции «пользователь» или создавать разные коллекции для каждого типа в корне,Каковы будут последствия использования обоих подходов.

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

Firestore-root
   |
   --- users
        |
        --- uid
        |    |
        |    --- userType: "admin"
        |    |
        |    --- //other user details
        |
        --- uid
        |    |
        |    --- userType: "driver"
        |    |
        |    --- //other user details
        |
        --- uid
             |
             --- userType: "rider"
             |
             --- //other user details

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

FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
Query query = rootRef.collection("users").whereEqualTo("userType", admin);

3) Сколько глубокой вложенности мне разрешено делать в одной коллекции, т.е.-коллекции в коллекциях?

Глубина может составлять до максимум 100 подколлекций.Согласно официальной документации по использованию и ограничениям :

Максимальная глубина вложений: 100

Вы можете спросить, это проблема?

Насколько я знаю, Firestore может так же быстро найти узел на уровне 1, как и на уровне 100. Поэтому для такой базы данных, как ваша, глубина не должна быть фактором, влияющим на скорость на техническом уровне.

4) Правильно ли мое решение использовать 2 разные базы данных в одних и тех же приложениях?

Да, это так.На самом деле, это довольно распространенная практика.В соответствии с обоими ценовыми планами вы можете выбрать, какой из них больше соответствует вашим потребностям.

5) Является ли Firebase правильным выбором для приложения, которое я создаю?

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

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