Каковы за и против объектных баз данных?

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

Ted Neward объясняет это и намного больше о OODBMSs намного лучше, чем это.

Я использовал db4o, который является OODB, и он решает большинство перечисленных недостатков:

• Знакомство - Программисты знают свой язык лучше затем SQL (см. Собственные запросы),
• Производительность - этот очень субъективен, но можно смотреть на PolePosition
• Поддержка поставщика и зрелость - могут изменяться со временем
• Не может использоваться программами, которые также не используют ту же платформу - существуют стандарты OODB, и можно использовать различные платформы
• Управление версиями является, вероятно, немного сукой - Управление версиями на самом деле легче!

Профессионалы, которыми я интересуюсь:

• Собственные запросы - Db4o позволяет Вам записать запросы на своем статическом типизированном языке, таким образом, Вы не должны волноваться о вводе с опечатками строки и нахождении данных, отсутствующих во времени выполнения,
• Простота использования - Определяющий buissiness логика в доменном слое, слой персистентности (отображение) и наконец база данных SQL является, конечно, нарушением DRY. С OODB Вы определяете свой домен, где он принадлежит.

Я соглашаюсь - OODB имеют длинный путь для движения, но они идут. И существуют доменные проблемы там, которые лучше решены OODB,

Sören

Все причины, которые Вы заявили, допустимы, но я вижу, что проблемой с OODBMS является логическая модель данных. Объектная модель (или скорее сетевая модель 70-х) не является столь же простой как реляционный и является поэтому нижней.

Недостатки:

• Не может использоваться программами, которые также не используют ту же платформу для доступа к хранилищу данных, делая более трудным использовать по всему предприятию.

• Меньше ресурсов, доступных онлайн для не основанная на SQL база данных

• Никакая совместимость через типы БД (не может подкачать другому поставщику дб, не изменяя весь код),

• Управление версиями является, вероятно, немного сукой. Я предположил бы добавление, что новое свойство к объекту не вполне так же легко как добавление нового столбца к таблице.

jodonnel, я' не вижу, как использование объектных баз данных связывает код приложения с данными. Можно все еще абстрагировать приложение от OODB до использования шаблона Репозитория, и замена ORM поддержала базу данных SQL при разработке вещей правильно.

Для приложения OO база данных OO обеспечит более естественное пригодное для сохранения объектов.

То, что, вероятно, верно, - то, что Вы связываете свои данные с Вашей моделью предметной области, но затем это - затруднение!

Разве не было бы хорошо иметь единственный способ посмотреть и на данные, бизнес-правила и на процессы с помощью доменного центрального представления?

Так, большое про - то, что OODB соответствует, как самый современный, объект уровня предприятия ориентируемые приложения разработаны, нет никакого дополнительного усилия разработать слой данных с помощью другого (реляционного) дизайна. Более дешевый, чтобы создать и поддержать, и во многих случаях общая более высокая производительность.

Недостатки, просто общее отсутствие зрелости и принятия я считаю...

Это не имеет ничего общего с производительностью. То есть практически все приложения будут лучше работать с OODB. Но это также избавит многих администраторов баз данных от необходимости изучать новую технологию. Еще больше людей остались бы без работы, исправляя ошибки в данных. Это вряд ли сделает OODB популярными среди известных компаний. Гэвин, кажется, совершенно невежественен, лучшая ссылка была бы Кирк