Почему объектно-ориентированные базы данных не были успешными (пока)?

Ответ 1

Можем ли мы ответить более одного раза? Другая причина заключается в том, что реляционная БД имеет прочную основу в математике: от определения отношения, вплоть до нормальных форм, теория прочная. Верно, что реляционная модель плохо сопоставляется с OO, но IMHO преимущества и стабильность этой модели перевешивают проблему сопоставления.

Ответ 2

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

Ответ 3

Я думаю, это потому, что "базы данных объектов" решают проблему, которая (почти) у кого-то действительно есть. Для простого сохранения графиков объектов сериализация, встроенная в большинство сред OO, достаточно хороша. Если вы хотите выполнять сложные операции над подмножеством ваших данных, то реляционная база данных и SQL идеально подходят.

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

Ответ 4

Просто потому, что OODB не является основным направлением, мы все равно должны учитывать успехи, которые у них были. Кэш и Zope широко используются (относительно), но будут считаться успешными по некоторым стандартам.

Возможно, самая большая причина, по которой OODB не увенчалась успехом, - это успех гибридных объектно-реляционных систем, которые занимают большую часть потенциальных рынков от OODB: PostgreSQL и Informix.

Я знаю, что это прямо не отвечает на вопрос, но это, я думаю, часть уравнения. В целом, однако, я думаю, что импульс и сильно укоренившиеся мыслительные процессы, поддерживающие базы данных отношений, затрудняют переход людей. В настоящее время профессия DB обучается почти исключительно в реляционной теории, что делает ваши профессионалы БД очень заинтересованными в том, чтобы избегать OODB, и ученые преподают теорию БД для практиков почти исключительно по реляционным.

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

Ответ 5

Ну, это странно, не так ли? Существует такой толчок к проектированию, ориентированному на домен, как зенит объектно-ориентированного анализа и проектирования, а также существуют корпоративные шаблоны для использования систем ORM для сохранения наших объектов. Мне просто кажется, что если ваше приложение DESIGN ориентировано на объект, а домен сосредоточен в глубине души, то OODB принесет большую пользу вашему приложению.

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

Но посмотрите, если вы не делаете дизайн дисковода домена и используете объекты в качестве объектов данных и как ваши сохраненные procs, то вы действительно не получите его;)

Ответ 6

RDBM (построенные на прочной теоретической основе, были на рынке гораздо дольше, могут более точно моделировать данные, чем OODB, могут использоваться более DBA, чем OODB). Это одна причина в форме реляционного кортежа.

Ответ 7

Если я могу усилить точку Фила: стандартизация SQL. OODB попробовал такие языки запросов, как OQL, но они никогда не соответствовали истинному стандарту. Кроме того, качество языков запросов было подозрительным, возможно, из-за отсутствия стандартизации. Стандарты способствуют конкуренции, которая порождает качество.

Ответ 8

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

Базы данных несколько аналогичны гексагексафлексгагонам.

Ответ 9

Это, и o/r-mappers. Через них разница с истинными OO-DB становится меньше, тогда как вышеупомянутые преимущества остаются в силе.

Ответ 10

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

Ответ 11

Я думаю, что есть две философские причины.

Во-первых, люди традиционно склонны отделять упорство от реальной функциональности. Как только вы удаляете объект "жизнь" от него и сохраняете его в первую очередь для настойчивости, он становится записью, и тогда есть тенденция рассматривать его как "безжизненный" объект данных.

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

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

Ответ 12

Причина медленного принятия OODB основана в основном на нескольких ключевых факторах, которые делают реляционные базы данных SQL более популярными и/или более подходящими. В то время как чистые объектно-ориентированные базы данных теперь находятся в состоянии, когда они преодолевают многие недостатки реляционной модели, отсутствуют некоторые ключевые фрагменты.

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

Вторая причина заключается в том, что очень немногие системы реализуют стандартный язык запросов и вместо этого используют язык программирования или специализированные языки запросов для извлечения и управления данными в хранилище. Это пробная пробная версия для многих, если им приходится изучать новый язык запросов в дополнение к совершенно другому мышлению программиста, используемого для решений на основе NoSQL. Кроме того, большинство баз данных на базе SQL/Relational теперь имеют некоторую поддержку Object Oriented Design, плюс у нас есть обертки, такие как ORM, которые многие используют для "обхода" проблем реляционных баз данных, которые не доступны на выбранном языке программирования.

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

Кто знает, что ждет в будущем?

Ответ 13

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

В настоящее время я думаю о том, чтобы сделать это в качестве моего проекта "Мастер-тезис", чтобы предоставить общую структуру для OODBMS, которая поддерживает почти все компоненты, которые обычно используются в СУБД сегодня, таким образом обеспечивая нелинейную структурированную СУБД. Во время изучения я столкнулся с проектом под названием db4o, который является подходом (реализованным) использования OODBMS для Java и .net, поэтому это может быть еще одной причиной отсутствия общности для всех типов платформ и языков.

Ответ 14

Я думаю, что, поскольку крупные парни, такие как Oracle, инвестировали в реляционные базы данных, в то время как объектно-ориентированное движение набирало обороты... возможно, они станут основными, если Oracle/Microsoft инвестирует в него большим образом... что кажется маловероятным потому что у них нет веских оснований для этого... это упростит жизнь многих программистов... но "сделать жизнь программистов проще" - это не очень хорошая бизнес-цель для них!