Одним из решений было бы сохранение документа владельца с одним полем, состоящим из списка объективных ссылок на документы ПК.Аналогично, документы ПК будут включать список объективных ссылок на документы частей.
Именно так MongoDB имитирует отношения.Подумайте о внешнем ключе SQL, который находится в дочернем элементе и ссылается на родительский, и меняет направление ссылки на : MongoDB сохраняет в родительском документе список объектов для своих дочерних элементов.
Но это не нормализация - это денормализация .Это похоже на хранение списка идентификаторов, разделенных запятыми, в РСУБД, который будет повторяющейся группой , которая разбивает первую нормальную форму .
Вы могли бы задаться вопросом, как узнать, какие ПК содержатзаданная часть, если ссылки хранятся в документах ПК.Для этого вам придется хранить избыточный список ссылок на ПК в документе Part, а затем беспокоиться о том, как вы собираетесь синхронизировать двунаправленные ссылки, рискуя аномалиями, когда ПК думает, что использует Part, ноэта соответствующая часть не имеет ссылки на ПК (или наоборот).
Вы можете создать документ MongoDB, имитирующий таблицу пересечения многие-ко-многим в SQL, где один документ содержит ровно одну объективную ссылку на ПК иодна ссылка на часть.Затем создайте много таких документов, как если бы вы создали много строк в таблице пересечений в SQL.Но поскольку это документы, а не строки, нет схемы, обеспечивающей, чтобы во всех документах хранилась только одна ссылка для каждой сущности.И нет такого понятия, как JOIN для эффективного поиска.
Это последствия денормализации и баз данных, ориентированных на документы, и почему реляционные базы данных все еще имеют некоторые преимущества.