Объектно-ориентированные базы данных все еще используются? - PullRequest
16 голосов
/ 09 декабря 2008

Некоторое время назад я слышал о объектных базах. Классная концепция и все. Теперь, когда события ORM повсюду, кто-нибудь еще использует какие-либо системы объектно-ориентированных баз данных? Они актуальны? Они практичны?

Ответы [ 10 ]

11 голосов
/ 09 декабря 2008

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

Тем не менее, есть еще несколько поставщиков OODBMS, таких как Gemstone , Versant или Cardinal , которые довольно хорошо работают со своими продуктами. Технология полезна для некоторых типов структур данных и может быть более эффективной, чем RDBMS, но имеет тенденцию быть слабой для специальных запросов по сравнению с современными диалектами SQL.

Как отметили различные другие , Gemstone привлекает немного внимания благодаря поддержке Побережье и Маглев (a порт Ruby для виртуальной машины Gemstone с Rails , работающими на нем). Мы можем обнаружить, что это привлекает внимание приятных людей из Gemstone и немного больше внимания к парадигме OODBMS.

7 голосов
/ 11 декабря 2008

На самом деле, системы баз данных являются одной из области, в которых происходят фундаментальные изменения действительно трудно. Миллиарды долларов потрачено на системы реляционных баз данных и они работают довольно хорошо.

В реальной жизни это просто неправда. Основной причиной наших проблем с базами данных (я утверждал, что 30% всех строк базы данных содержат ошибки) является использование очень примитивной типизации и проверки в SQL. Кроме того, даже если они называются реляционными, они очень плохо справляются с отношениями. Результатом являются денормализованные модели данных и возникающие в результате ошибки обновления.

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

4 голосов
/ 09 декабря 2008

Я недавно начал использовать Gemstone. GLASS (Gemstone в Linux (или OS-X) с Seaside (веб-среда smalltalk)), вероятно, является лучшей средой веб-разработки для сложных приложений. Smalltalk делает возрождение, будучи "настоящим рубином".

Поддержка изменений схемы и запросов намного лучше, чем в СУБД.

Важным отличием является то, что на этот раз они доступны по цене.

4 голосов
/ 09 декабря 2008

На самом деле, системы баз данных являются одной из областей, в которых фундаментальные изменения действительно сложны. Миллиарды долларов тратятся на системы реляционных баз данных, и они работают довольно хорошо. Это проверенная технология, и они были достаточно гибкими, чтобы удовлетворить большинство потребностей (например, используя ORM, как вы сказали). Объектные базы данных действительно существуют даже вне академических кругов. Но не ожидайте увидеть что-либо столь же большое, как SQL Server или Oracle в этой области в ближайшее время. Они существуют как теория и как маленькие, специфичные для приложения базы данных и различные продукты. По сути, я предсказываю, что в будущем реляционные базы данных станут более объектно-ориентированными, чтобы лучше обрабатывать требования.

4 голосов
/ 09 декабря 2008

Выезд db4o .

3 голосов
/ 03 сентября 2009

Потому что стоимость их программного обеспечения не так легко узнать.

Я проверил Objectivity, db4o, versant, и ни у одного из них нет цены на программное обеспечение на их сайте.

Я уже почти потерял интерес только из-за этого.

Кто-нибудь знает где-нибудь, где есть сравнение цен и лицензий для всех этих разных вариантов?

3 голосов
/ 09 декабря 2008

Мы используем База данных объектов Versant в продукте, над которым я работаю. (Ранее FastObjects, ранее база данных Poet). Это объектная база данных, и мы находим, что она работает намного лучше, чем реляционная модель для некоторых аспектов нашего продукта, в первую очередь для хранения объектов конфигурации, взаимодействия с кодом Java.

Смотрите также этот ранее заданный вопрос: https://stackoverflow.com/questions/52144/object-oriented-database-experiences

2 голосов
/ 10 декабря 2008

Использование GemStone для крупного бизнес-приложения. Это здорово и очень практично. Мы использовали его в течение нескольких лет, и за это время это позволило нам сделать очень мало ресурсов. К сожалению, существуют и были многочисленные заблуждения относительно объектных баз данных, и я думаю, что это делает их менее актуальными в деловом мире. Надеюсь, что-то вроде GLASS (GemStone, Linux и Seaside Smalltalk) изменит это в будущем.

1 голос
/ 16 июля 2010

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

Я думал, что Data Engine (не обязательно Object Database) и RDBMS действительно могут жить бок о бок, на самом деле, есть отличное место для Data Engine в промежуточном уровне, Embedded Apps / systems. .. Кроме того, правильная реализация механизма данных позволит поддерживать персистентность объектов на низкоуровневом и высокоуровневом конструкциях RDBMS / SQL. Это означает, что ваше приложение может выбрать работу с объектами, использовать механизм данных для сохранения объектов и сделать объекты доступными в виде строк / столбцов таблицы через интерфейс RDBMS.

Это идеальная настройка. Мы соединяем две технологии и предоставляем разработчикам альтернативы для программирования в их предпочтительном интерфейсе. Можно утверждать, что мы имеем это сейчас, например - SQL Server поддерживает хостинг объектов CLR, НО текущие реализации страдают от замедления импеданса. то есть - в пути данных много преобразований / переводов как Objects! = двумерные данные, таким образом, когда ваше приложение, которое имеет дело с объектами, сохраняет их в БД, решение должно преобразовать / преобразовать их в данные строки в таблице.

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

Так что, может быть, следующая волна технологий в этой области - это механизм обработки данных, который позволит объектам работать в качестве низкоуровневого интерфейса и интерфейса СУБД. И эта технология доступна уже сейчас!

B-Tree Gold версия 4.0. Стойкость масштабируемых объектов - это главная цель дизайна. Он достигает следующих характеристик и, таким образом, он хорошо приспособлен к тому, чтобы быть выбранным механизмом данных для следующей СУБД, которая, по сути, является слоем поверх нее. Два из его основных ключевых моментов: Масштабируемость: 100 млн. Вставок за 17 часов в обычном ноутбуке со средним / средним значением. Стабильность: промышленная транзакция, которая гарантирует, что БД не повреждена и может откатиться до ранее зафиксированного состояния.

Чтобы это работало, движок данных должен соответствовать масштабируемости и стабильности, требуемой для серверов RDBMS. Очень сложная задача, но не невозможная. S-версия B-Tree Gold версии 4.0 выполнила это требование, поэтому мы действительно готовы реализовать такое решение, не заталкивая его себе под нос, поскольку SOP дает свободу выбора того, как вы хотите его использовать. Его можно использовать многими способами, например, - дополняют серверы СУБД в качестве станции кэширования среднего уровня, встроенной БД на стороне клиента и т. д., не говоря уже о том, что они являются низкоуровневым механизмом данных самого сервера СУБД!

0 голосов
/ 09 декабря 2008

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

...