Реализация отношений «многие ко многим» в Firestore

Question

Мне нужно смоделировать отношение «многие ко многим» в Firestore.Краткое изложение требований приведено ниже.

1. Компания может нанять много подрядчиков для проекта.Подрядчик может работать для многих компаний в разных проектах в разное время.

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

3. Подрядчик должен иметь возможность запрашивать компании;и наоборот, компания должна иметь возможность запрашивать у подрядчиков.Например, (1) подрядчик может запросить список компаний, для которых он / она работал, отсортированный по проекту и времени, и (2) компания может запросить всех подрядчиков, которые работали на них более месяца, отсортированных по проекту и подрядчику,и, возможно, делится на неделю.

4. Что касается компании, подрядчик может изменить статус, например, рабочий, завершен.Компания меняет статус подрядчика в течение срока реализации проекта.Этот статус можно использовать в запросах.

5. Очевидно, подрядчики не должны иметь доступа к информации других подрядчиков.

6. Компания представлена ​​только одним пользователем в мобильном приложении.Аналогично, подрядчик представлен только одним пользователем в мобильном приложении.

7. Мобильное приложение встроено в React Native, которое (насколько я знаю) Firestore рассматривает как веб-приложение.

Я подумываю об использовании подгруппы документов для / под каждой компании. Каждый документ представляет проект. Все имена подрядчиков, их статусы, время начала и окончания хранятся в этом документе.

В то же время, имеется дубликат сборника проектных документов для / под каждого подрядчика. Каждый из этих дубликатов документов представляет собой частичную копию документа проекта (см. Выше).Этот дубликат документа хранит название компании, время начала и окончания проекта.

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

б.Статус существует только на 1-м экземпляре документа.

c.В случае каких-либо редких изменений почти статических данных, например.имя, телефон, оба документа обновляются.

Имеет ли этот дизайн смысл?Есть проблемы, предложения, лучшие идеи?Если вы согласны с дизайном, я хотел бы услышать от вас, возможно, вы можете написать в комментарии что-то вроде звучит хорошо

AskFirebase

Answer 1

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

Когда использовать вложенные коллекции:

1) Если вы не хотите хранить много полей в документе. Облачный Firestore имеет ограничение в 20 000 полей. (Если информация о Компании и Подрядчике очень велика и может превышать более 20 000 полей)

2) При обновлении родительской коллекции это обычная операция. Firestore позволяет обновлять документ только со скоростью 1 запись в секунду. (Если информация о Компании и Исполнителе изменяется очень часто)

3) Если вы хотите ограничить доступ к определенным полям документа. (Если вы хотите ограничить доступ к подрядчикам Компании или если доступ к компаниям Подрядчика должен быть ограничен. В этом случае перенос ограниченных полей в другой документ в другой коллекции также является хорошей идеей!)

Когда не использовать вложенные коллекции:

1) Когда вы хотите запросить коллекции и вложенные коллекции вместе. Запросы Firestore мелкие. Таким образом, подзапросы не будут запрашиваться при запросе родительской коллекции, поэтому вам придется запрашивать их отдельно. (Если у вас есть случай, чтобы показать все компании и их подрядчиков в одном окне)

2) Когда вы хотите показать вложенную коллекцию при просмотре коллекции. (При отображении компании вы, возможно, захотите показать ее подрядчиков. Здесь число операций чтения увеличится, поскольку вместо чтения одного документа вы читаете один документ и его подколлекция все время)

3) Когда вы хотите запрашивать коллекции и подколлекции вместе (вы можете использовать недавно объявленный запрос группы коллекций всякий раз, когда вы хотите запросить что-то общее для компаний и подрядчиков, такое как поле работы или минимальная ставка)

4) Если вы думаете о запросе отдельных фрагментов данных, вы должны поместить их в коллекцию. (Если конкретные атрибуты Подрядчика обычно запрашиваются компаниями или сведения о компании рассматриваются несколькими подрядчиками)

Мое предложение:

Company коллекция для хранения информации о компании, по которой компании можно искать по их качествам.

Contractors коллекция с тем же подходом, так как я предполагаю, что у подрядчиков будет много запросов в соответствии с их атрибутами.

Projects субколлекция для получения информации о проектах, по которым компании и подрядчики будут сотрудничать. Это может быть подколлекция в разделе Коллекция компании, если над проектом будет работать только одна компания. Даже если несколько подрядчиков будут работать над проектом для компании, вы можете сохранить идентификаторы подрядчика в массиве в коллекции Projects. Это поможет вам избежать частичной вложенной коллекции Projects внутри каждой коллекции Company / Contractor.

Но если вам нужно узнать о качествах проекта, лучше представить их как отдельную родительскую коллекцию. Я оставляю это на ваше усмотрение.

Наконец, я бы предложил новую коллекцию Contracts, которую можно использовать для хранения взаимосвязей между Company, Contractor и Project и всей информации, с которой вы можете выполнять сложные запросы. Если у одной и той же компании и подрядчика есть два разных проекта, над которыми они работают / сотрудничают, то это может быть два документа в коллекции Contracts. Это удобно, когда вы хотите показать некоторые панели. Используя эту единую коллекцию, вы можете отобразить отдельную статистику для компании, подрядчика и комплексную статистику, включающую как компанию, так и подрядчика.

Надеюсь, это поможет.