Каковы плюсы и минусы баз данных объектов?

Существует много информации о объектно-реляционных картографах и о том, как наилучшим образом избежать несоответствия импеданса, все из которых кажутся спорными, если нужно использовать базу данных объектов. Мой вопрос: почему это не используется чаще? Это из-за причин производительности или из-за того, что базы данных объектов приводят к тому, что ваши данные становятся собственностью вашего приложения или это связано с чем-то еще?

Ответ 1

  • Знакомство. Администраторы баз данных знают реляционные концепции; объектов, не так много.
  • Производительность. Реляционные базы данных, как оказалось, значительно улучшились.
  • Зрелость. SQL - мощный, долго развитый язык.
  • Поддержка поставщиков.. Вы можете выбирать между многими другими сторонними (SQL-серверами) и сторонними (административными интерфейсами, сопоставлениями и другими типами интеграции) инструментами, чем в случае с OODBMS.

Естественно, объектно-ориентированная модель более знакома разработчику и, как вы заметили, зарезервировала бы один из ORM. Но до сих пор реляционная модель оказалась более работоспособной.

См. также недавний вопрос Объектно ориентированный и реляционные базы данных.

Ответ 2

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

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

Про меня интересуют:

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

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

Ответ 3

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

Тед Ньюард объясняет это и многое другое о OODBMS намного лучше, чем это.

Ответ 4

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

Ответ 5

Минусы:

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

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

  • Совместимость между базой данных   типы (не могут поменяться на другой db   провайдера без изменения всех   код)

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

Ответ 6

Сьёрен

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

Ответ 7

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

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

Что, вероятно, верно в том, что вы привязываете свои данные к своей модели домена, но тогда это круче!

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

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

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