MongoDB-идиоматический способ иметь массив DBRefs для РАЗНЫХ типов
Итак, в настоящее время у нас есть коллекция, содержащая массив DBRef(x, ObjectId). Массив имеет значение «дети». Дело в том, что x неоднозначен, поэтому в нашей коллекции могут быть дети, которые находятся в разных коллекциях.
Денормализация, конечно, возможна, но дети действительно живут сами по себе и заслуживают своих собственных коллекций, поэтому я бы предпочел держать их отдельно.
По какой-то причине DBRef явно злые/неэффективные (хотя я не смог выяснить, почему, подробности здесь также будут оценены по достоинству).
Теперь главный вопрос: как бы вы это реорганизовали (если не денормализовали)? Скажем, x может быть vegetable, fruit или meat. Должны ли мы затем изменить массив дочерних элементов на несколько массивов:
vegetables, fruits, meats каждый представляет собой плоский массив ObjectId? Или каков был бы обычный идиоматический способ?
Из документации MongoDB : Unless you have a compelling reason to use DBRefs, use manual references instead.
@Джо, конечно. Хоть и не отвечает на мой вопрос
Ответы 1
«Обычный идиоматический способ», вероятно, лучше всего описан в https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design блогпосте. Версия TL;DR - это зависит.
«Идиоматическая» часть mongodb заключается в переходе от проектирования схемы хранения данных (способ SQL) к разработке схемы для извлечения данных. Т.е. не думайте о данных «объектно-ориентированным» способом, делая отношения между сущностями ключевой проблемой - в конечном итоге вы будете бороться с базой данных вместо того, чтобы использовать ее. Вместо этого подумайте о данных с точки зрения приложения — как вы храните данные (оптимизировано для записи) и как вы извлекаете данные (оптимизировано для чтения). Схема должна быть разработана на основе формы запросов с учетом того, как часто будет выполняться каждый тип, насколько важно быстро получать данные, как часто вы собираетесь обновлять данные, какую пользу вы можете получить от индексов и атомарных обновлений, как эффективно распределять его между шардами и т.д.
По какой-то причине DBRefs, по-видимому, являются злыми/неэффективными (хотя я не смог понять, почему, подробности здесь также будут оценены по достоинству).
Я могу пролить на это некоторый свет. DBRef был единственной возможностью ссылаться на документы до того, как $lookup был введен в версии 3.2.
Он не такой гибкий, как $lookup, и вызывает некоторые проблемы с импортом/экспортом, поскольку нарушает соглашение об именах полей, начинающихся с $, поэтому https://www.mongodb.com/docs/manual/reference/database-references /#use-1 явно говорит
В большинстве случаев вам следует использовать метод ручной ссылки для соединения двух или более связанных документов. Однако если вам нужно ссылаться на документы из нескольких коллекций, рассмотрите возможность использования DBRefs.
Могу только добавить, что DBRef по-прежнему является единственным способом (начиная с версии 7.0) ссылаться на документы в другой базе данных. Это должно быть довольно нишево, так как https://jira.mongodb.org/browse/SERVER-34935 реализация межбазового поиска остается в резерве более 5 лет.
В нем есть довольно хорошая информация, поэтому я отметил это как ответ, спасибо :)
Есть ли какие-то причины/принципиальные различия между "детями"? В MongoDB данные, к которым осуществляется совместный доступ, предназначены для совместного хранения. На самом деле одним из самых больших преимуществ MongoDB является обработка документов со схожей структурой в одной коллекции. Вы можете получить всех дочерних элементов в одном
$lookup, например этом. И да, вы умны, чтобы избегать DBRefs :)