Основные NoSQL дизайн документ вопрос

Question

Я пытаюсь выяснить, как наилучшим образом реализовать это для моей системы ... и получить мою голову из РСУБД пространства для теперь ...

Часть моей текущей БД имеет три таблицы: Show, ShowEntry и Entry. В основном ShowEntry - это многозначная таблица соединений между Show и Entry. В моем RDBMS мышлении это вполне логично, так как любые изменения Show details могут быть сделаны в одном месте, и то же самое с Entry.

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

FYI, я в настоящее время рассматриваю возможность внедрения RavenDB. В то время как обсуждения общего дизайна NoSQL будут хорошими, более ориентированный на RavenDB будет фантастическим!

Спасибо, D.

Answer 1

При моделировании отношений «многие ко многим» в базе данных документов вы обычно храните коллекцию внешних ключей только в одном из документов. Документ, который вы выбираете, в значительной степени зависит от того, какое направление вы намерены пересечь. Обход его в одну сторону тривиален, а другой путь требует индекса.

Возьмите пример корзины покупок. Более важно точно знать, какие предметы находятся в определенной корзине, чем корзины содержат определенный предмет. Поскольку мы обычно следуем за отношениями в направлении корзины к пункту, имеет смысл хранить идентификаторы предметов в корзине, чем для хранения идентификаторов корзины в элементе.

Вы можете по-прежнему пересекать отношения в противоположном направлении (например, найти корзины, содержащие определенный элемент), используя индекс, но индекс будет обновляться в фоновом режиме, чтобы он не всегда был на 100% точным. (Вы можете дождаться, когда индекс станет точным с WaitForNonStaleResults, но эта задержка покажет в вашем пользовательском интерфейсе.)

Если вам требуется немедленная точность 100% в обоих направлениях, вы можете хранить внешние ключи в обоих документах, но ваша заявка при каждом создании или уничтожении отношений придется обновлять два документа.

Answer 2

This прошла долгий путь к решению моего вопроса!