Почему реляционные базы данных более распространены, чем объектно-ориентированные?
Если парадигма объектно-ориентированного программирования так широко распространена, разве мы не должны увидеть много ООСУБД? Разве они не будут работать лучше, чем RDBMS+OR/M?
Одна из причин, по которой СУБД сохранила свою популярность, заключается в том, что она использует устоявшуюся технологию, хорошо понятна и имеет стандартный язык (SQL), который поддерживают несколько поставщиков. Он также имеет несколько хороших интерфейсов, таких как ODBC и JDBC, которые позволяют ему довольно хорошо подключаться к различным языкам. Стабильный API — важный фактор в сохранении доминирующего положения технологии.
Напротив, для ООСУБД нет ни четкой модели, ни стандартного языка, ни стандартного API. Нет даже стандарта де-факто, если у вас есть реализация от ведущего поставщика.
Концепция ООСУБД может работать лучше, чем РСУБД+ORM. Это полностью зависит от реализации. Но также верно и то, что ООСУБД не решают тот набор проблем, с которыми хорошо справляются РСУБД. Некоторые задачи управления данными намного проще, если у вас есть ссылочная целостность и реляционные заголовки, принудительно реализованные решением для управления данными. Эти функции отсутствуют в модели ООСУБД (по крайней мере, пока).
В блогах много шума о том, что реляционные базы данных устарели, но РСУБД, тем не менее, являются лучшим универсальным решением для подавляющего большинства задач управления данными.
Самая большая проблема, которую я видел, это отсутствие стандартизации. В мире СУБД вы можете продвинуться довольно далеко с любой случайной базой данных, если знаете SQL. Они в основном все это реализуют, с небольшими вариациями. Я не знаю ни одной существующей СУБД, которая не выполняет SQL: вы можете почти взаимозаменяемо использовать «СУБД» и «SQL».
Ближе всего к ООСУБД, пожалуй, OQL, который потерпел полный провал.
Ни одна база данных никогда не реализовывала многое из этого. Пару лет назад я использовал довольно хорошую коммерческую ООСУБД, но (по состоянию на 2007 год или около того, и это было в основной версии 8 или 9) она даже не поддерживала запрос объекта по его имени. В руководстве просто говорилось, что до этой части OQL они еще не дошли. (Я не уверен, но вы, возможно, смогли бы сделать это в собственном вызове.)
Большинство объектных баз данных, которые я недавно видел, имеют интерфейсы на родном языке, а не язык запросов, такой как OQL. Система, которую я использовал, например, поддерживала (только!) Perl и VB, IIRC. Ограничение вашей аудитории всего парой языков (или принуждение их к написанию оберток, как это сделали мы) — не способ завоевать друзей.
Из-за этого нет конкуренции и, следовательно, нет простого резервного плана. Если вы поместили свои данные в MS-SQL, а Microsoft прекратила его поддержку, вы, вероятно, сможете сбросить свои данные в Postgres и перенести свои запросы без особых проблем. (Это может быть много работы, если у вас много запросов, но я не сомневаюсь, что вы справитесь. Это больно, но технически не сложно.) Или Oracle, или MySQL, или многие другие, как коммерческие и бесплатно.
С ООСУБД такого не происходит: если та, которую вы используете, развалится, или они поведут ее в направлении, которое вам не нужно, или вы обнаружите, что в ней отсутствует ключевая функция, которая вам нужна, вы не можете просто сбросить ее. ваши данные в конкурирующую ООСУБД и портировать ваши запросы. Вместо этого вы говорите об изменении базовой библиотеки и внесении масштабных изменений в архитектуру. Так что на самом деле вы ограничены коммерческой ООСУБД, которой вы действительно доверяете (можете ли вы назвать хотя бы одну?), или ООСУБД с открытым исходным кодом, которую вы доверяете своей команде поддерживать, когда что-то пойдет не так.
Если это звучит как FUD, извините, я не хотел этого. Но я был там, и с точки зрения управления проектами я бы не решился вернуться, даже несмотря на то, что среда программирования может быть прекрасной. Другой способ думать об этом таков: посмотрите, насколько сегодня популярно функциональное программирование, несмотря на то, насколько это хорошая идея. ООСУБД похожи, но хуже, поскольку это не просто ваш код, а ваш код и ваши данные. Я бы с радостью начал сегодня крупный проект на Erlang, но я все еще не решился бы использовать ООСУБД.
Поставщики ООСУБД: чтобы изменить это, вам нужно упростить переход от вас к конкурентам . Вы можете найти OQL и реализовать это на самом деле или сделать это на уровне API, например, ODBC или что-то в этом роде. Даже стандартный формат дампа (с использованием JSON?) и инструменты для импорта/экспорта в/из него для нескольких ООСУБД были бы отличным началом.
Данные часто живут дольше и важнее программы. Так что, даже если вы начнете разработку с нуля сегодня, вы должны учитывать общую картину. Есть больше инструментов, процессов и опытных людей, работающих с системами RDBM. Подумайте не только о программе, как насчет планирования мощностей, интеллектуального анализа данных, отчетности, ETL, интеграции с другими источниками данных и т. д. Как насчет того, чтобы ваша компания приобрела другую компанию и, таким образом, включила все их реляционные данные в свою программу. РСУБД и связанные с ней инструменты настолько хорошо зарекомендовали себя, проверены и мощны, что я не вижу никакого стратегического смысла в использовании чего-либо еще. В какой-то небольшой нише может быть, но не в целом.
Базы данных объектов имеют очень хорошую нишу для таких задач, как представление геометрии, например. CAD-системы, в которых графы объектов могут быть действительно очень глубокими. Производительность JOIN быстро снижается примерно для 7 таблиц в большинстве реляционных систем, поэтому глубоко самореферентные структуры в САПР работают лучше в объектных базах данных.
Но важные приложения, такие как финансовые данные, поддаются реляционному представлению. Реляционная модель имеет прочную математическую основу, а SQL — успешный и популярный язык. У финансовых учреждений, таких как банки, брокерские конторы и страховые компании, мало стимулов для отказа от СУБД.
Для тривиальных примеров ООБД и РБД могут сильно отличаться. Особенно, если вы работаете с достаточно небольшим объемом данных, чтобы вы могли тривиально прочитать их все в память сразу и записать все сразу. Но в конечном итоге ООБД необходимо сохранять данные в формате, очень похожем на РБД, — они не так уж и отличаются.
Рассмотрим произвольный граф объектов, которые можно использовать в приложении. На каждый объект может ссылаться несколько других объектов. Когда вы сохраняете граф объектов, вы не хотите сохранять объекты повторно каждый раз, когда на них ссылаются. Во-первых, если бы у вас был какой-либо цикл или ссылка на себя, ваш метод сохранения объекта вошёл бы в бесконечный цикл. Но в общем случае это пустая трата места. Вместо этого любое важное хранилище данных должно объявлять уникальный идентификатор для каждого сохраняемого объекта (ключ, обычно суррогатный ключ в терминах СУБД). Каждый другой объект, который ссылается на него, сохраняет тип объекта и ключ, он не сохраняет повторно весь объект. Итак, здесь мы воссоздали внешние ключи в нашем хранилище объектов, отличном от RDB.
Далее представьте, что мы хотим сохранить список объектов (A1, A2, A3...), которые связаны с другим объектом (B). Мы уже установили, что будем хранить ключи вместо того, чтобы дважды сохранять сами объекты. Но храните ли вы ключи к объектам A1, A2, A3... в объекте B или храните ключ к объекту B в A? Если вы сохраните их первым способом и у вас есть все А, которые вы хотите, вы можете быстро получить соответствующие Б. Во втором случае верно обратное. Но в любом случае это односторонняя сделка. Если вы хотите запросить обратное тому, что вы сохранили, а ваши объекты хранятся в виде XML или JSON, это много неэффективного синтаксического анализа самой нерелевантной информации для поиска ключа в каждом файле. Не лучше ли было бы хранить их в формате, в котором каждое поле было бы разделено, как столбцы в таблице?
В отношениях «многие ко многим» или в случае, когда вам нужно найти большое количество объектов в обоих направлениях, эта стратегия становится очень неэффективной. Единственное эффективное решение состоит в том, чтобы создать вспомогательный объект для хранения отношения с одним файлом для каждого отношения, чтобы файл состоял из ключа A и ключа B, чтобы их можно было быстро найти. Мы только что заново изобрели таблицу перекрестных ссылок.
Таблицы со столбцами, уникальные идентификаторы (ключи), таблицы перекрестных ссылок... Это основные потребности для хранения объектов таким образом, чтобы их можно было эффективно извлекать. Хм... Это звучит как что-то знакомое? Реляционная база данных обеспечивает именно эту функциональность. Кроме того, несколько поставщиков на протяжении десятилетий конкурировали за обеспечение самого быстрого хранения и извлечения данных с помощью лучших инструментов для резервного копирования, репликации, кластеризации, запросов и т. д. Это много для новой технологии, с которой можно конкурировать. И, наконец, я говорю, что РСУБД — это действительно хорошее решение проблемы эффективного хранения объектов.
Вот почему существует что-то вроде Hibernate — чтобы поместить объектно-ориентированный интерфейс в эффективную систему хранения RDBMS. Там, где вы видите, что другие виды хранения действительно блестят, есть разные проблемные области:
ООБД не могут работать лучше, чем РБД, потому что они принципиально не отличаются друг от друга.
РБД никуда не денутся, потому что сохраняют большие графы объектов таким образом, который экономит пространство и время как для сохранения, так и для извлечения, а также отказоустойчив и некоторая гарантия целостности данных — это проблема, для решения которой в первую очередь были разработаны РБД. Вот почему JPA и Hibernate никуда не денутся — потому что они ликвидируют разрыв между объектной и реляционной моделями данных. Объектная модель для простоты манипулирования памятью и реляционная для сохраняемости.
Одним словом Интероперабельность (громкое слово в пятницу вечером ‹G›)
Большинству предприятий приходится работать с устаревшими системами, работающими на СУБД. Если бы они использовали ООСУБД, им по-прежнему требовался бы доступ к РСУБД для определенных функций. Легче поддерживать один способ доступа к данным, чем два.
Когда у вас есть такие громкие имена, как Oracle и SQL Server в мире ООСУБД, и проверенная производительность в различных средах, ТОГДА вы увидите больше проектов, использующих их.
Я думаю, это случай
Если он не сломан, не меняйте его.
Реляционные базы данных чрезвычайно укоренились.
Основная проблема была в индексации!
Индексировать значения скаляров действительно удобно... Просто сортирует их.
Для значений со многими атрибутами, методами, частями, компонентами и т. д. Не существует общих правил…
Итак, ООСУБД исчезают, как динозавры!
Но поставщики СУБД интегрируют некоторые средства для хранения объектов в базе данных, таких как XML (иногда проводятся исследования и разработки, чтобы найти способы индексации для специальных действительно используемых объектов, но это очень сложно….), а также для поддержки хранения любых объектов. (без возможности его индексировать...) обычно на Java (Oracle) или .net (SQL Server).
Самый прямой ответ на вопрос, почему реляционные базы данных более распространены, чем объектные базы данных, заключается в том, что большинство проблем можно решить с помощью реляционных баз данных. У подавляющего большинства людей есть определенный набор инструментов, которые они используют каждый день для решения почти всех проблем, с которыми они сталкиваются. Это так же верно и для программистов. Многим программистам нужна только реляционная база данных, поэтому рынок реляционных баз данных создан для их обслуживания.
Однако, если вы разрабатываете программное обеспечение для индустрии CAD/CAM/CAE, или если вы разрабатываете приложения для анализа связей для поддержки исследований, или если вы строите сложную систему слияния данных, у вас, вероятно, есть база данных объектов/графов в вашем наборе инструментов, потому что они выполняют намного лучше, чем реляционные базы данных в этих областях.
Отказ от ответственности: я работаю в компании Objectivity, Inc., где мы производим, продаем и продаем масштабируемую распределенную базу данных объектов/графов.
