Объектно-ориентированная база данных - почему большинство компаний не используют их

Question

Я довольно новичок в программировании (только что закончил университет).

В последние 4 года я думал об объектно-ориентированной разработке и многочисленных преимуществах этого подхода.

Мой вопрос

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

Почему объектно-ориентированные базы данных не настолько распространены, как реляционные?

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

Answer 1

Работая в прошлом в компании, занимающейся объектно-ориентированной базой данных ( http://www.objectstore.com/) - и в настоящее время - я думаю, что у меня есть четкое представление о том, что делает их великими, а что - не такими уж хорошими.

Большой:

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

Нет объектно-реляционного несоответствия - вы развиваетесь в объектах, вы думаете в объектах, вы храните в объектах.

Нет столь велика:

ORM: объектно-реляционные менеджеры в значительной степени сделали базы данных объектов неактуальными

Эволюция схемы: измените класс, чтобы добавить поле, и теперь вам нужно изменить всю базу данных. За эти годы ObjectStore стал умнее, но для многих OODBMS это все еще является проблемой.

Плохой:

Поддержка инструментов - это то, что сделало OODBMS не стартером для большинства мест. Сегодня каждый может взять Crystal Reports или Access или Excel и собрать множество отчетов. При использовании OODBMS вам придется создавать эту логику с помощью программиста, и мы все знаем, насколько быстро это произойдет, когда вам нужно, чтобы ваш бюджетный отчет учитывал какой-то параметр xyz, о котором вы не думали во время разработки.

Инструменты - это то, почему OODBMS потерпела неудачу на рынке. Не техническое превосходство, не производительность или поддержка языков (ObjectStore поддерживает C++/Java/.Net и имеет поддержку COM для поддержки любых языков IDispatch, таких как VB, Perl и т. Д.).

Поэтому я сказал здесь несколько пренебрежительных слов, особенно о продукте, который мне действительно нравится. Но ObjectStore великолепен в очень специфических задачах, но плохой выбор для создания веб-приложения. Хотя в какой-то момент это было движущей силой управления запасами для Amazon.com.

Answer 2

Как вы утверждаете, вы только что закончили колледж и только что были интенсивно внушены Единый Истинный (Объектно-ориентированный) путь. Если, с другой стороны, вы изучили декларативное программирование, проектирование баз данных и теорию множеств, вы бы поняли, что реляционная модель является совершенно адекватным подходом, хорошо обоснованным в теории, тогда как ОО - более прагматичный подход, который был изобретен в основном в промышленности. а не академия. Как оказалось, наиболее интересные исследования и разработки по проблемам баз данных проводятся людьми с большим математическим опытом, для которых реляционная модель является более естественным способом работы с данными. В результате СУБД имеют тенденцию быть более стабильными, масштабируемыми и надежными, чем их объектно-ориентированные аналоги. Объектно-ориентированные базы данных, во многом как XML, часто используются в необдуманной попытке привести данные в соответствие с программами, которые их используют, а не наоборот.

Answer 3

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

Answer 4

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

Тем не менее, существует движение в сторону от реляционных баз данных, см. Движение NoSQL. Я считаю, что Google не использует реляционную базу данных (но также не объектно-ориентированную, а скорее что-то проприетарное и распределенное).

Answer 5

Извиняюсь за то, что не смог добавить это как комментарий в том месте, где это действительно должно появиться.

Но следующее представляет собой личную атаку на меня, и я ссылаюсь на свое право на ответ.

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

FWIW, мне наверняка НЕ ​​"промыли мозги" тому, что вы, вероятно, могли бы назвать "религиозной верой отношений". Промывание мозгов - это когда какой-то наставник что-то говорит, и ученик слепо и безмозгло принимает это как единственную истину без какой-либо формы критического мышления. На самом деле, меня даже никогда не учили реляционной модели. На самом деле, мне пришлось открыть все это самому. Фактом является то, что я выразил серьезную критику в отношении мнений Дейта по поводу обновления представления. (исправление: "был" - вопрос зарегистрированного факта. Кажется, что страница была удалена с сайта, где она была опубликована. Вероятно, это связано с тем фактом, что Дата действительно отказалась от позиции обновления представления, которую я критиковал.)

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

Причина, по которой RM вытеснил иерархические и сетевые модели, была подробно задокументирована во всех библиотеках, полных книг по этой теме. Я приглашаю вас внимательно осмотреть их.

Что касается "ключевой ценности - захватывает рынок": вы совершенно свободны в принятии "самого распространенного мнения рынка" (то есть посредственного большинства слишком ленивых, чтобы думать за себя дураков, которые вполне счастливы позволить себе (и их мнению) быть ведомыми Эллисонами, Вратами и Иовами этого мира) в качестве основного критерия того, что ценно, а что нет. Я лично считаю, что это глупо, но это только мое личное мнение. Я копирую и вставляю здесь некоторые наблюдения, сделанные кем-то, кто сталкивается с ужасами EAV и Key-value почти каждый день своей профессиональной жизни:

Я работаю над приложением, которое использует следующую "модель EAV" (по крайней мере, "модель EAV", как я понимаю) для многих, но не всех, логических таблиц:

R1 {EAV_RELVAR_NAME*, ... }
R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...}
R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}

В котором можно увидеть следующие значения:

R1 { {'STATE_CODES'} }
R2 { {'STATE_CODES', 1, 'STATE_NAME', 'CHAR(30)'} ,
     {'STATE_CODES', 2, 'STATE_CODE', 'CHAR(2)' } ...}
R3 { {'STATE_CODES', 'ALABAMA', 'AL'} ,
     {'STATE_CODES', 'ALASKA',  'AK'} ...}

По сути, "EAV relvars" создаются / изменяются / удаляются с помощью вставок / обновлений / удалений в R1 и R2 (по сравнению с DDL). Это урезанная версия нашей общей модели: в R1 и R2 есть дополнительные столбцы для указания eav-primary-keys, eav-foreign-keys, бизнес-правил и т. Д. - все это обеспечивается процедурным кодом, встроенным в "один". Истинная передняя часть "модели.

Этим утром я был причастен к испытанию более 20 человеко-часов, которое произошло, когда Система A думала, что CODE_XYZ будет в ATTRIBUTE2, но Система B фактически определила его в ATTRIBUTE3... Мне пришлось смеяться над тем фактом, что я наполовину слушал к разговору, и половину чтения дискурса этой группы на EAV.

В прошлом месяце мне пришлось добавить экстренное обновление (16 человеко-часов плюс "плохие оценки" для приложения), чтобы изменить ATTRIBUTE16 с "МАЯ 2010" на "МАЙ-2010" для 430 введенных пользователем точек данных.

Около 5-10% наших выпусков кода сопровождается "очисткой от ошибок среды выполнения в понедельник утром", поскольку EAV_RELVAR не были закодированы в R1 или R2 идентично в производстве, как это было сделано в ходе тестирования / разработки (код приложения и DDL переносятся с строгое управление версиями программного обеспечения... наша модель EAV не связана с такой бюрократией, поскольку она "позволяет" разработчикам устанавливать свои EAV автономно в dev, test и prod.).

В прошлом году я потратил целых 3 недели на настройку программного обеспечения для репликации исключительно для решения проблемы отсутствия первичного ключа на R3.

Однажды мне пришлось извиниться за невозможность поместить индекс ATTRIBUTE4 в EAV_RELVAR_NAME_x, так как это ухудшало производительность другой программы, которая использовала EAV_RELVAR_NAME_z.

Два года назад, после нескольких лет потраченных сотен часов постоянной настройки сложных запросов, которые должны были присоединиться к R3, я, наконец, потратил 3 месяца на разделение R3 на сотни физических разделов (по одному на EAV_RELVAR_NAME), чтобы дать оптимизатору СУБД статистику нужно было увидеть, например, 50 'STATE_CODES' и 200 000 'LOCATION_CODES'. Меня поздравили с гениальным решением, хотя ирония была упущена всеми, когда я указал, что с этим изменением будет новая политика, согласно которой добавление нового EAV_RELVAR_NAME повлечет за собой запуск сценария, добавляющего связанный раздел в R3 (да, с DDL).

Моим клиентам нужен новый интерфейс для загрузки данных в R3 для одного из их EAV_RELVAR_NAME (при соблюдении всех соответствующих ограничений и безопасности), и они хотят знать, почему на сборку уйдет 4 месяца.

Я часто отмечаю, что могу переписать всю систему EAV так, чтобы она превосходила во всех отношениях, используя динамический DDL против словаря данных вместо DML против R1 и R2, но я всегда информирован, что мы "преданы делу" "к этому подходу (для его создания потребовались предварительные расходы в 7 цифр, и нам пришлось бы переписать 98% нашей базы кода для перехода на отдельные таблицы), и что цели не оправдывают средства,

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

Answer 6

Одной из причин, почему принятие объектно-ориентированных баз данных является настолько медленным, является то, что не так много масштабируемых альтернатив OpenSource. Для RDBMS есть, например, MySQL (сейчас принадлежит Oracle), PostgreSQL и многие другие.

Другая проблема состоит в том, что, по крайней мере, для Java стандартные API для доступа к СУБД JDBC и JPA для части ORM имеют более крупные компании и более известны. JDO для объектно-ориентированного доступа к базе данных является стандартом, но не так популярен.

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

Для меня лично популярные базы данных OpenSource OO были бы причиной потратить больше времени на их опробование.

Answer 7

База данных - это не только хранение и извлечение объектов, в противном случае ООБД и БД документов захватили бы весь мир. Другие контексты / аспекты использования включают в себя:

• Агрегирование данных и выполнение сложной массовой обработки данных / манипуляций. СУРБД очень хороши в этом.
• Другим важным аспектом является параллелизм / изоляция (т.е. транзакции). СУБД очень зрелые в этой области.
• Другим аспектом является индексация для обеспечения быстрых запросов.
• Другой аспект, такой как "Крис Камински", упомянутый выше, - это возможность со временем изменять вашу схему, сохраняя данные.

Наконец, происходит некоторая инерция отрасли: крупные поставщики не хотят ставить деньги на то, за что клиенты не готовы платить, а клиенты ждут в стороне, пока крупные поставщики не присоединятся к игре.

Answer 8

Для этого нет веских причин, особенно в связи с ростом использования ORM (Active Record) и трудностями картирования. Объектно-ориентированные базы данных быстрее и лучше во многих отношениях. Причиной не популярности является необходимость. До сих пор RDBMS работали хорошо, и в крупных компаниях наибольшую боль называют "миграцией". Как и в большинстве технологий, первостепенной задачей является потребность пользователя, а объектная ориентация обычно не является точкой продажи. Возможно, скорость, но дорогое оборудование и проверенная настройка RDBMS также могут достичь производительности.

Кроме того, люди, которые имеют опыт в этой области, должны пройти повторное обучение (что стоит денег). Не говоря уже о дорогих консультантах, которые выучили зло PL/SQL...

Я бы сказал, быть первопроходцем. Как сказал Махатма Ганди, будь тем изменением, которое ты хочешь увидеть. Забавно, вы просто заставили меня хотеть Google для OO-DB с открытым исходным кодом.

Answer 9

Другая проблема - языковая поддержка. А как насчет языков, которые не являются объектно-ориентированными? Хорошая база данных должна быть доступна каждому, независимо от того, на каком языке. Вот почему многие языковые базы данных терпят неудачу, потому что их рынок - это люди только этого языка.

Существует также фактор миграции. Крупнейшие пользователи MySQL - давние пользователи. Переход на совершенно новую систему баз данных с совершенно другим фундаментальным дизайном и большим существующим будет очень дорогим и не принесет особой выгоды.