Объектно Ориентированные БД

[stalxed]

Купил книгу NoSQL Мартина Фаулера и Прамодкумара Дж. Садаладжа.
Пока нет времени, прочитал только первую главу.
В ней Фаулер пророчит, что NoSQL Базы Данных не вытеснят SQL БД, но откусят большую долю рынка.
В этой главе Фаулер похоронил Объектно Ориентированные БД. Почему они умерли, он затруднился ответить.

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

Кто-нибудь использовал объектно ориентированные БД(особенно на PHP)? Они ещё существуют(существовали)?
Просто кто-нибудь может в образовательных целях рассказать про объектно ориентированные БД?

 

[AnrDaemon]

Попробуй ответить на вопрос, почему трёхмерную структуру сложнее упаковать в одно измерение, чем двумерную?

 

[stalxed]

Попробуй ответить на вопрос, почему трёхмерную структуру сложнее упаковать в одно измерение, чем двумерную?

А ещё легче сохранять данные вида ключ-значение. И что?
Просто различных ООП оберток над реляционной БД даже в PHP море.
И работают... Весьма не плохо(хотя лично не одной подобной обертке, даже доктрине отлично не поставлю).
Объединить подобную ООП обертку и реляционную БД в один продукт возможно.

До меня доходит, почему люди этого не хотят.

Сейчас во многих приложениях: код бизнес области <=> ООП обертка над реляционной БД <=> реляционная БД.
Суть в том, что общение между ООП оберткой и реляционной БД происходит по стандарту SQL.
Т.е. можно:

• одну реляционную БД можно относительно легко заменить на другую
• одну ООП обертку можно относительно легко заменить на другую

В случае с ОО БД реально жесть. В теории будет некая директория с бинарными файлами, содержащими данные. И что с ним делать? Конвертировать не во что, ибо нет стандартов ОО БД.
Т.е. обанкротился производитель ОО БД - 1/3(плюс минус) вашего приложения тоже идёт на дно.

Т.е. подобных страх и явился смертельным приговором ОО БД?

Кстати я соврал, сейчас перечитал, Мартин Фаулер сказал, что реляционные БД стали популярны благодаря стандарту SQL, и роли реляционных баз как интеграционных баз данных(integration database). И по его мнению, это же стало гибелью ОО БД.

 

[AnrDaemon]

А ещё легче сохранять данные вида ключ-значение. И что?

И ничего. ООП обёртки так и поступают. Плодят тонну K-V таблиц без зазрения совести. Чтобы потом эту же БД интегрировать в другой проект, приходится разбираться с её оберткой и либо её же использовать, что ограничивает в выборе языка, либо реализовывать идентичную структуру самому, что открывает кадушку проблем совместимости.

Просто различных ООП оберток над реляционной БД даже в PHP море.
И работают... Весьма не плохо(хотя лично не одной подобной обертке, даже доктрине отлично не поставлю).
Объединить подобную ООП обертку и реляционную БД в один продукт возможно.

До меня доходит, почему люди этого не хотят.

Да как раз хотят… Только толку от этого хотения. БД это инструмент. Ты не будешь использовать инструмент, работающий неизвестно как. Либо ты должен ему доверять, либо ты должен иметь возможность его починить/заменить. Т.е. должен быть СТАНДАРТ. Нет стандарта = нет доверия к инструменту = …ты пишешь свой инструмент, который ты можешь сам починить либо изменить.

 

[fixxxer]

Они ещё существуют(существовали)?

Вполне существуют, хотя это скорее гибриды:

Caché

OpenLink Virtuoso

 

[флоппик]

Oracle OLAP заимел поддержку многомерных кубов данных + Oracle XML DB еще в начале двухтысячных, потом у них появился и Oracle NoSQL и "кровавый энтерпрайз" вполне с этим работает многие годы.

 

[grigori]

А ещё легче сохранять данные вида ключ-значение. И что?
Объединить подобную ООП обертку и реляционную БД в один продукт возможно.

Если бы это было несложно - были бы примеры таких систем или хотя бы попытки их создать.

А вот

• одну реляционную БД можно относительно легко заменить на другую
• одну ООП обертку можно относительно легко заменить на другую

в живых проектах почти никто не делает. Смена маппинга на новую платформу обычно означает смену фреймворка и переписывание всего приложения.

Реальность скучнее. ЦП внутри себя выполняет всего одну операцию - сложение. Все объекты и многомерные структуры сводятся в одномерный поток. Нормализованные двухмерные структуры РСУБД транслируются в одномерный поток сигналов по математической формуле, для объектных такая формула намного сложнее. РСУБД заставляет нас оптимизировать структуры данных с учетом физики сервера, а с документо-ориентированными NoSQL и объектными БД мы напишем какую-то абстрактную оторванную от реальности фантазию.

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

 

[флоппик]

grigori, я бы сказал, что проблема на самом деле растет от попыток запихать реляционные данные в документориентированную структуру. Документоориентированные бд — ок, для своих задач по хранению произвольно структурированных данных.

 

[grigori]

Попытки вызваны желанием с помощью роликов, статей и выступлений откусить кусок большого рынка баз данных для бизнес-логики.
Если нужно большое удобное хранилище для документов с индексами и вложенностью - его стоит использовать одновременно с СУБД, не вместо,
но если данных не так уж много - цена поддержки гетерогенности превышает выигрыш от производительности.

 

[stalxed]

в живых проектах почти никто не делает. Смена маппинга на новую платформу обычно означает смену фреймворка и переписывание всего приложения.

Я с этим полностью согласен.
Но часто виден тренд вида:
- читаешь документацию какой-нибудь ORM, повсюду фразы типа - так лучше не делать, вы потеряете возможность перейти на другую реляционную СУБД, галактика в опасности;
- люди хвастаются, что их продукт может в теории работать с разными СУБД;
- когда кто-то делает зависимый от конкретной СУБД код - ему все кричат, что так лучше не делать, теряется независимость от конкретной реляционной СУБД.
Может подобная возможность просто успокаивает людей?

Нормализованные двухмерные структуры РСУБД транслируются в одномерный поток сигналов по математической формуле, для объектных такая формула намного сложнее

Суть в том, что для реляционных БД такая математическая модель разработана.
Для ОО БД нет. Неужели всё на самом деле упирается в теоретическую невозможность такой модели для ОО БД?
Ведь выше fixxxer, привёл примеры ОО БД. Я гуглил существующие ОО БД, они всё таки как-то, да существуют...

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

Важное уточнение, откусить кусок пирога у рынка реляционных СУБД.
Не является ли, к примеру, ввод JSON в PostgreSQL защитной реакцией на атаку со стороны NoSQL?

Если нужно большое удобное хранилище для документов с индексами и вложенностью - его стоит использовать одновременно с СУБД, не вместо
но если данных не так уж много - цена поддержки гетерогенности превышает выигрыш от производительности.

Мне кажется, что ближайшие годы - различные производители БД и сопутствующих инструментов будут пытаться уменьшить цену поддержки.
Например PHP Docrine пытается с одинаковым, более менее, API работать как с реляционными, так и с документными NoSQL БД.

В теории это звучит клёво:

• новости и статьи вешаем на документную NoSQL БД;
• иерархическое меню на иерархическую NoSQL БД;
• кеш и постоянно меняющиеся мелкие данные на NoSQL БД типа ключ-значение;
• всё остальное кидаем на реляционную БД.

НО!, даже если будет единая ОО API для работы с этим зоопарком, что уменьшит расходы на внедрение, то как обеспечить целостность данных?

 

[Absinthe]

то как обеспечить целостность данных?

Внедрение NoSQL в реляционные СУБД.
PostgreSQL уже это сделал.