Почему объектно-ориентированные базы данных перестали работать? [закрытый]
SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%wild%';
10 ответов
Я использовал db4o (объектно-ориентированная база данных) в последнее время о моих личных проектах с домашними животными, просто потому, что его так быстро настроить и начать. Не нужно вдаваться в мелкие, грубые детали.
Помимо этого, на мой взгляд, основные причины, по которым они не стали популярными, следующие:
- Отчетность сложнее в объектно-ориентированных базах данных. В связи с этим также легче вручную просматривать фактические данные в реляционной базе данных.
- Microsoft и Oracle основывают значительную часть своего бизнеса на реляционных базах данных.
- Многие предприятия уже имеют реляционные базы данных.
- 128] ИТ-отделы часто имеют опыт работы с реляционными базами данных.
И, как отметил Ян Агард,
Probably because of their coupling with specific programming languages.
Во-первых, я не верю, что они полностью "провалились". Некоторые из них все еще существуют, и, насколько мне известно, они все еще используются парой компаний
, во всяком случае, вероятно, потому, что многие данные, которые мы хотим хранить в базе данных, имеют реляционный характер. Проблема в том, что хотя да, объектно-ориентированные базы данных легче интегрировать в объектно-ориентированные языки программирования, реляционные базы данных упрощают определение запросов и, в общем, отношений между хранящимися данными. Часто это самая сложная часть.
Существует бесчисленное множество существующие приложения хранят свои данные в реляционных базах данных. Эти данные - источник жизненной силы этих компаний. Они коллективно вложили огромные средства в хранение, ведение и отчетность по этим данным. Стоимость и риск переноса этой бесценной информации в принципиально иную среду чрезвычайно высоки.
Теперь представьте, что инструменты ORM могут отображать современные структуры данных приложений в традиционные реляционные модели, и вы практически полностью устраняете любые стимулы для перехода на OODBMS. Они представляют собой альтернативу с низким уровнем риска очень дорогостоящей миграции с высоким риском.
Потому что, несмотря на то, что реклама ODBMS была перегружена уничижительными словами о системах ORM, было не так уж сложно заставить ORM выполнять работа, и без всех различных ударов, возникающих при переключении на чистую ODBMS.
На самом деле произошло то, что победил ваш первый образец кода,
Very subjective, but a few reasons come to mind:
Performance has not been as good as relational databases (or at least that's the perception)
Again with performance - relational databases allow you to do things like denormalizing data to further improve performance.
Legacy support for all the non-OO apps that need to access the data.
Думаю, это потому, что проблема решалась иначе. Вы можете за кулисами использовать реляционную базу данных, когда пишете код на Ruby on Rails или LINQ to SQL, но вам кажется, что вы работаете с объектами.
I think a lot of your answer lies in the "Why we abandoned Object Databases" answer of "Object Oriented vs Relational Databases".
As far as your example goes, it doesn't have to be that way. Linq to SQL is actually a quite nice basic layer over a DBMS, and Linq to Entities (v2 -- v1 sucked) will be pretty cool too. (N)Hibernate has been solving the problem you're having for years now using RDBMSes.
So I guess my answer to you is that O/R mappers are getting to the point where they solve your problem nicely, and you don't need an ODBMS to get what you need.
Why not?
I guess they were a solution to a problem nobody was having, or not having enough to pay for it.
Further, OOP and set-based programming are not always very comptatble. Personally, when I started reading about OO databases, I couldn't help but think "Boy, I hope I never have to work on one of those, update 1 million rows out of a 6 million row table and then make sure all appropriate records in other tables get updated as well"