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

Ответ 1

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

Отлично:

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

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

Нет ничего хорошего:

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

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

Плохо:

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

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

Что касается "ключевого значения", то вы полностью можете принять "наиболее распространенное мнение рынка" (то есть: посредственное большинство слишком-ленивых к мысли о себе дураков, которые весьма счастливы позволить себе (и их мнениям) возглавить Эллисон и Гейтс и Джобс этого мира) в качестве основного критерия того, что ценно, а что нет. Я лично считаю, что это глупо, но это только мое личное мнение. Я скопирую здесь несколько замечаний, сделанных кем-то, кто сталкивается с ужасами 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, бизнес-правил и т.д.... все принудительно введено в процедурный код, встроенный в" один true front end "модели.

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

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

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

В прошлом году я потратил целую трехнедельную программу репликации тюнинга исключительно для устранения нехватки первичного ключа на 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 приведет к запуску script, который добавит связанный раздел в R3 (да, с DDL).

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

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

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

Ответ 6

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

• Агрегирование данных и обработка сложных операций обработки/обработки массовых данных. RDBMSes очень хороши в этом.
• Другим важным аспектом является concurrency/изоляция (т.е. транзакции). RDBMS очень зрелые в этой области.
• Другим аспектом является индексирование для обеспечения быстрых запросов.
• Еще один аспект, например, "Chris Kaminski", упомянутый выше, способен с течением времени развивать вашу схему, сохраняя данные.

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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