Отношения многие ко многим в Монго

Question

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

У меня есть система планирования событий для создаваемой мной CRMэто позволяет назначать события как пользователям, так и командам.Эти события характерны для каждого отведения.

Так, например, в четверг в 5:00 вечера мне позвонят с Джимми Дулиттлом.В четверг в 7:00 моя команда по продажам также позвонила Бобу Джонсу.

Если бы это был SQL, я бы просто создал таблицу потенциальных клиентов, таблицу событий, таблицу пользователей и таблицу команд.Я думал о том, чтобы поместить события в коллекцию пользователей и в коллекцию команд, но тогда возникает проблема, когда у меня есть список потенциальных клиентов, и я хочу отобразить дату обратного вызова рядом с каждым потенциальным клиентом.Подобные ссылки в Монго будут неопрятными со списком из 500 клиентов.

Я также думал о сохранении событий в коллекции потенциальных клиентов, но это означало бы, что мне придется выполнять поиск потенциальных клиентов с событиями, назначенными определенному пользователю или команде (может быть 500 000 потенциальных клиентов).в базе данных, но только 500 имеют события для конкретного пользователя.

Answer 1

Такого рода отношения просто станут проблемой в Монго. В этой ситуации я, вероятно, написал бы функцию для соединения этих объектов на уровне приложения. Всякий раз, когда устанавливается соединение, сохраняйте отношения в обоих объектах. Тогда вы можете легко найти любое направление. У вас будут избыточные данные, и это приведет к риску их несинхронизации, но это цена, которую вы должны заплатить с нереляционной структурой. Ваши обновления не будут такими быстрыми, поскольку вам придется обновить два документа, но ваш выбор должен быть быстрым.

Answer 2

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

Что я хотел бы сделать, это создать новую коллекцию 'Events' и затем сохранить массив _id связанных событий внутриобъекты пользователя и команды отсюда будет очень быстро сделать поиск.Это может означать гораздо больше запросов, но запросы только в одном поле _id являются высокооптимизированными и не очень ресурсоемкими (если только у вас нет миллионов событий на пользователя), поэтому, если у команды есть приложение, они могут видеть свои события и, если пользователь имеетОни могут видеть свои события.

Также я рекомендую хранить обратные ссылки на пользователя и команду _id в объекте события.Да, это избыточные данные, но это только ссылка, и при правильном управлении на уровне приложения схема должна быть аккуратной и аккуратной.

Best of Luck.