Почему объектно-ориентированные базы данных терпят неудачу?

Ответ 1

Я использую db4o (объектно-ориентированная база данных) в последнее время в моих личных проектах для домашних животных, просто потому, что так быстро настроить и начать работу. Нет необходимости в подробных подробностях.

В стороне, как я вижу, основными причинами, по которым они не стали популярными, являются:

• Отчетность более сложна для объектно-ориентированных баз данных. В связи с этим также легче вручную просмотреть фактические данные в реляционной базе данных.
• Microsoft и Oracle используют большую часть своей работы в реляционных базах данных.
• У многих предприятий уже есть реляционные базы данных.
• ИТ-отделы часто имеют опыт реляционной базы данных.

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

Ответ 2

Возможно, из-за их связи с конкретными языками программирования.

Ответ 3

Во-первых, я не верю, что они "провалились" полностью. Насколько я знаю, они все еще существуют, и они все еще используются несколькими компаниями.

в любом случае, вероятно, потому, что многие данные, которые мы хотим сохранить в базе данных, носит реляционный характер. Проблема в том, что, хотя да, базы данных OO легче интегрировать в языки программирования OO, реляционные базы данных упрощают определение запросов и, ну, отношения между хранимыми данными. Это часто сложная часть.

Ответ 4

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

Теперь рассмотрим, что инструменты ORM могут сопоставлять современные структуры данных приложений с традиционными реляционными моделями, и вы удаляете практически любой стимул для перехода на OODBMS. Они обеспечивают альтернативу низкого риска для очень дорогостоящей миграции с высоким уровнем риска.

Ответ 5

Поскольку, поскольку рекламные объявления ODBMS были нагружены уничижительным языком в отношении систем ORM, было не так сложно заставить ORM выполнять эту работу, и без всех различных обращений при переключении на чистую ODBMS.

Что на самом деле произошло, так это то, что ваш первый образец кода выиграл, он просто находится на уровне сохранения RDBMS.

Ответ 6

Я думаю, это потому, что проблема была решена по-разному. Возможно, вы используете реляционную базу данных за кулисами, когда вы кодируете Ruby on Rails или LINQ to SQL, но похоже, что вы работаете с объектами.

Ответ 7

Очень субъективно, но приходят на ум несколько причин:

• Производительность не так хороша, как реляционные базы данных (или, по крайней мере, это восприятие)

• Снова с реляционными базами данных производительности вы можете делать такие вещи, как денормализация данных для дальнейшего повышения производительности.

• Поддержка Legacy для всех приложений, не относящихся к OO, которым необходимо получить доступ к данным.

Ответ 8

Я думаю, что ваш ответ кроется в ответе "Почему мы отказались от объектных баз данных" "Объектно-ориентированные и реляционные базы данных".

Насколько ваш пример идет, это не обязательно должно быть так. Linq to SQL на самом деле довольно хороший базовый уровень над СУБД, а Linq to Entities (v2 - v1 sucked) тоже будет довольно крутым. (N) Hibernate решает проблему, с которой вы работаете в течение многих лет, используя RDBMS.

Итак, я полагаю, что мой ответ на ваш вопрос заключается в том, что O/R mappers доходят до того, что они хорошо решают вашу проблему, и вам не нужна ODBMS, чтобы получить то, что вам нужно.

Ответ 9

Почему бы и нет?

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

Ответ 10

Кроме того, OOP и программирование на основе набора не всегда очень сложны. Лично, когда я начал читать о базах данных OO, я не мог не думать "Мальчик, я надеюсь, что мне никогда не придется работать над одним из них, обновите 1 миллион строк из таблицы из 6 миллионов строк, а затем убедитесь, что все соответствующие записи в других таблицах также обновляется"

Ответ 11

Они преуспеют в один прекрасный день. Это будущее.

Оглядываясь назад на технологии программного обеспечения в истории, эта тенденция приносит в жертву производительность, чтобы уменьшить сложность (Assembly = > C = > C++ = > .NET). Приложение, которое занимает 30 минут для кода, через несколько дней прошло месяц.

ORMs - правильный ответ на неправильный вопрос. В настоящее время они являются выбором, поскольку они облегчают жизнь в отсутствие лучшего решения. Но они не могут справиться с уровнем сложности, к которому они стремились. "Проблемы не могут быть решены тем же уровнем мышления, который их создал". A.E

Как упоминалось ранее, реляционные базы данных в значительной степени используются, и они полагаются и заменяют их множеством рисков. Посмотрите интервал между версиями SQL и основными изменениями между этими версиями и другими продуктами Microsoft (консервативный подход, который необходим здесь). Также я добавлю следующие элементы:

• Текущий подход все еще работает. Вы можете утверждать, что это будет работать вечно (мы может еще выполнить сборку кода), но здесь я имею в виду, что это не работают логически, когда, СРЕДНИЙ уровень сложности проектов и время их разработки на реляционных базах данных вызывает звонок.
• Крупные компании серьезно не занимались. Когда рынок сигнализирует, они делают.
• Проблема пока не определена. К сожалению, текущие сбои помогают.
• Нужны некоторые улучшения в других науках (QC, AI), а не компьютер. Хранение и запрос многомерных данных на плоские инфраструктуры и без достаточной ловкости для самоорганизации верхние препятствия на теоретическом уровне.