I предположим, вы думаете с точки зрения внешних ключей, как в sql DB. Что обычно происходит в сценарии без sql, так это то, что вы должны избегать отношений и - вставлять отношения в "большой" документ (document = json объект в не sql).
Там для этого нет указания c rece ie.
То, что Алекс пытался объяснить, это то, что вы должны подумать, что является центральным элементом вашего дизайна. Похоже, что это элемент 'item'.
Возможный дизайн может быть:
Сохранить категорию и местоположение в виде простого текста в объекте json, представляющем ваш элемент. .
Затем используйте массив для перечисления элементов в интерфейсе
Наконец, используйте функцию JS array.filter () для интерфейс для фильтрации того, что отображается в ответ на действия пользователя.
Если вам нужно показать только элементы, принадлежащие пользователю, добавьте поле «пользователь» в документ «элемент» и попросите firestore вернуть только те документы, чье поле 'user' соответствует вашему зарегистрированному пользователю.
Это немного устарело, но должно помочь вам понять денормализацию данных в no sql: https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html?m=1
Редактировать
В отношении ответа Джея и статьи MongoDB, указанной в комментариях, я всегда изо всех сил старался принять решение: если встраивать данные или ссылаться на них, но я ' Мы всегда заканчивали тем, что встраивали маленькие документы.
Можете ли вы, Джей, поделиться своим опытом?
Мне всегда было довольно скучно создавать дополнительные запросы в интерфейсе, чтобы присоединиться к необходимой информации (а-ля sql), хотя редко у меня есть преимущества в указании других small документов. Я предполагаю, что это в основном зависит от дизайна приложения.
Короче говоря
Я предпочитаю что-то вроде
users_collection > user_uuid_0
{
"name": "John"
"items": [
{/*...plain item1 object here...*/},
{/*...plain item2 object here...*/},
/*...*/
]
}
Вместо:
users_collection > user_uuid_0
{
"name": "John"
"items_ids":[
"item_uuid_0",
"item_uuid_1",
/*...*/
]
}
---
items_collection > item_1
{
/*all item fields*/
"belong_to": "user_uuid_0"
}
items_collection > item_2
{
/*all item fields*/
"belong_to": "user_uuid_0"
}
Преимущества последнего решения заключаются в большей гибкости и развязке: вы можете изменять пользовательские данные без какого-либо влияния на элементы, и ваши полезные нагрузки будут меньше (если размер trafi c важнее, чем количество операций в вашем сервисе) .
минусы: требуется 2 запроса к БД (1, чтобы получить пользователя, сделать c, и один, чтобы получить элементы, отфильтрованные по id), против 1; требуется несколько операций над интерфейсом, чтобы вспомнить все, а не добавленных операций, так как предыдущая компоновка do c уже встраивает все.
Первая работает хорошо, если:
- у вас отношения один к нескольким (один ко многим склоняется к ссылкам uuid, как предложено Джэем)
- ваши документы маленькие (в противном случае решение Джея снова будет лучше)
- если вы оплачиваете операцию, а не трафик c размер
Когда мы думаем об управляемой базе данных no sql, такой как firestore, где, как правило, ваш CRUD API в основном представляет собой REST API или что-то очень близкое к этому (без JPA, DTO-проекций и т. д.), по моему опыту, первый макет лучше подходит.
Но, опять же, это в основном связано с дизайном приложения и Стоимость услуг.