Это может быть немного запоздалым в ответе, но я подумал, что стоит отметить, что между ODB и MongoDB есть большие различия.
В целом, фокус ODB - это прозрачные ссылки (отношения) междуобъекты в произвольно сложной модели предметной области без использования и управления кодом для чего-то вроде DBRef.Даже если у вас есть пара тысяч классов, вам не нужно беспокоиться об управлении какими-либо ключами, они предоставляются бесплатно, и когда вы создаете экземпляры этих тысяч классов во время выполнения, они автоматически создают схему в базе данных ... дажедля таких вещей, как самоссылающийся объект с коллекциями коллекций.
Кроме того, ваши транзакции могут охватывать эти ссылки, поэтому вам не нужно использовать полностью встроенную модель.
Концепции - это те, которые используются в решениях ORM, таких как JPA, жизненный цикл управляемого постоянного объекта.цикл, берется из пространства ODB, но ОГРОМНОЕ различие заключается в том, что в ODB нет сопоставления AT ALL, и отношения хранятся как часть базы данных, поэтому отсутствует JOIN времени выполнения для разрешения отношений, все отношения разрешаются одинаково.скорость как B-дерево поиска.Для тех из вас, кто использовал Hibernate, вообразите Hibernate без ЛЮБОГО файла отображения и на порядок быстрее, потому что за кулисами нет времени выполнения JOIN.
Кроме того, ODB разрешает запросы по любым отношениям в вашей модели, поэтому вы не ограничены запросами в конкретной коллекции, как в MongoDB.Конечно, поддерживаются индексы hash / b-tree / aggregate, поэтому запросы очень бывают быстрыми, когда они используются.
Вы можете создавать экземпляры любого класса в ODB на уровне класса и во время выполнения - правильный класс.версия разрешена.Совсем иначе, чем то, как это работает в MongoDB, поддерживающем код, чтобы решить, как обращаться с различными формами BLOB-объектов (или объектов-значений), возникающих в результате развития базы данных без схемы ... или написания кода для посещения и изменения каждого объекта-значения, посколькуВы хотели изменить схему.
Что касается разбиения на части, я думаю, что гораздо проще выбрать модель разбиения для модели предметной области, которая может взаимодействовать между произвольными объектами, чем вычислятьbe-all, end-all стратегия встраивания для вашей коллекции содержала документы в MongoDB.Например, у вас есть контакт, адрес и корзина покупок, и они связаны в документе JSON, и вы решили разделить контакт по Contact_id.Абсолютно ничто не мешает вам рассматривать эти 3 класса как просто объекты вместо документов JSON и сохранять их с разделом в Contact_id так же, как вы это делаете с MongoDB.Однако, если у вас был другой объект Account, и вы хотели управлять им не встроенным способом из-за некоторых совокупных операций выставления счетов, выполняемых с учетными записями, вы можете иметь это бесплатно (не нужно создавать код для типа DBRef) в ODB... и вы можете выбрать разделение на части вместе с Контактом или сохранить учетные записи в совершенно отдельном физическом узле, но все они будут подключены во время выполнения в пространстве приложения ... точно так же, как по волшебству.
Если вы хотите посмотреть действительно классное видео о том, как создать приложение с ODB, которое показывает распределение, перемещение объектов, отказоустойчивость, оптимизацию производительности ... посмотрите это (если вы хотите перейти к классной части, перейдите к 21минут, и вы избежите сборки приложения и просто увидите, как легко добавить распространение и отказоустойчивость к любому существующему приложению):
http://www.blip.tv/file/3285543