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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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" создаются / изменяются / удаляются с помощью вставок / обновлений / удалений в R1 и R2 (по сравнению с DDL).Это урезанная версия нашей общей модели: в R1 и R2 есть дополнительные столбцы для указания первичных ключей eav, внешних ключей eav, бизнес-правил и т.д. Истинный передок »модели.

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

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

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

В прошлом году я потратил целых 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, но мне всегда сообщают, что мы ' re "привержены" этому подходу (на его создание были внесены 7-значные авансовые расходы, и нам пришлось бы переписать 98% нашей кодовой базы, чтобы переключиться на автономные таблицы), и что конечные точки этого не делают оправдать средства.

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