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

Question

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

Я нахожу это удивительным, что:

foo bar = new foo(); 

bar.saveToDatabase(); 

Проиграла:

foo bar = new foo(); 
/* write complicated code to extract stuff from foo */ 
/* write complicated code to write stuff to database */ 

вопросы, связанные с:

Are Object oriented databases still in use?

Object Oriented vs Relational Databases

Why have object oriented databases not been successful (yet)?

Answer 1

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

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

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

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

Answer 2

Почему нет?

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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

Answer 11

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

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

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

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

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