Подтвердить что ты не робот

Все еще используются объектно-ориентированные базы данных?

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

4b9b3361

Ответ 1

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

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

В качестве различных других отметили, что Gemstone получает немного внимания из-за их поддержки Seaside и Maglev (порт Ruby в Gemstone VM с Rails работает в теме). Мы можем обнаружить, что это дает хорошим людям из Gemstone немного давления и с ним немного больше внимания к парадигме OODBMS.

Ответ 2

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

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

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

Ответ 3

Отметьте db4o.

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

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

Ответ 10

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