Почему базы данных отношений более распространены, чем объектно-ориентированные базы данных?
Если парадигма объектно-ориентированного программирования настолько распространена, разве мы не должны видеть много OODBMS? Разве они не будут работать лучше, чем RDBMS + OR/M?
Одной из причин, по которым RDBMS сохраняет популярность, является то, что она создала технологию, хорошо понятна и имеет стандартный язык (SQL), поддерживаемый несколькими поставщиками. Он также имеет несколько хороших интерфейсов, таких как ODBC и JDBC, которые делают его очень удобным для общения на разных языках. Стабильный API является сильным фактором сохранения доминирующей технологии.
В отличие от этого, нет четкой модели для OODBMS, нет стандартного языка и нет стандартного API. Там даже не стандарт де-факто, имея ведущую реализацию поставщика.
Концепция OODBMS может работать лучше, чем RDBMS + ORM. Это полностью зависит от реализации. Но также верно, что OODBMS не решают один и тот же набор проблем, которые RDBMS хорошо решают. Некоторые задачи управления данными намного проще, если у вас есть ссылочная целостность и реляционные заголовки, введенные в действие решением управления данными. Эти функции отсутствуют в модели OODBMS (по крайней мере, до сих пор).
В блогах много шума, что реляционные базы данных устарели, но RDBMS все же являются лучшим универсальным решением для подавляющего большинства задач управления данными.
Самая большая проблема, которую я видел, - это отсутствие стандартизации. В мире РСУБД вы можете получить довольно далеко от любой случайной базы данных, если знаете SQL. В основном они реализуют его с небольшими вариациями. Я не знаю ни одной существующей РСУБД, которая не выполняет SQL: вы почти можете использовать "RDBMS" и "SQL" взаимозаменяемо.
Самая близкая вещь для OODBMS - это, возможно, OQL, который был полным провалом.
Ни одна база данных никогда не выполняла ее. Я использовал довольно красивые коммерческие OODBMS пару лет назад, но (по состоянию на 2007 год или около того, и он был на основной версии 8 или 9), он даже не поддерживал запрос объекта по его названию. В руководстве было сказано, что эта часть OQL, с которой они еще не добрались, пока не дошла. (Я не уверен, но вы могли бы спуститься в собственный вызов, чтобы сделать это.)
Большинство баз данных объектов, которые я видел недавно, имеют интерфейсы на родном языке, а не язык запросов, например OQL. Система, которую я использовал, например, поддерживала (только!) Perl и VB, IIRC. Ограничение аудитории только несколькими языками (или принуждение их писать обертки, как мы это делали) - это не способ завоевать друзей.
Из-за этого нет конкуренции и, следовательно, нет простого плана резервного копирования. Если вы поместите свои данные в MS-SQL и Microsoft перестанет его поддерживать, вы можете, возможно, сбросить свои данные в Postgres и перенести свои запросы без особых проблем. (Это может быть много работы, если у вас много запросов, но я не сомневаюсь, что вы это сделаете. Это боль, но не технически сложная задача.) Или Oracle, или MySQL или многие другие, как коммерческие и бесплатно.
Нет такой вещи с OODBMS: если тот, который вы используете, взлетает вверх, или они принимают его в направлении, не полезном для вас, или вы обнаружите, что ему не хватает ключевой функции, которая вам нужна, t просто сбрасывайте свои данные в конкурирующие OODBMS и переносите свои запросы. Вместо этого вы говорите об изменении основной библиотеки и изменении массивной архитектуры. Настолько реалистично, что вы ограничены коммерческой OODBMS, которой вы действительно доверяете (можете назвать хотя бы один?), Или OODBMS с открытым исходным кодом, которым вы доверяете своей команде, чтобы поддерживать, когда что-то ухудшается.
Если это звучит как FUD, извините, я этого не хотел. Но я был там, и с точки зрения управления проектами я бы не стал возвращаться, хотя среда программирования может быть замечательной. Еще один способ подумать: посмотрите, как популярное функциональное программирование сегодня, несмотря на то, что это хорошая идея. OODBMS - это так, но хуже, поскольку это не только ваш код, но и ваш код и ваши данные. Я бы с радостью начал крупный проект в Эрланге сегодня, но я все равно не стал бы использовать OODBMS.
Поставщики OODBMS: чтобы изменить это, вам нужно упростить отправку для ваших конкурентов. Вы можете выкопать OQL и фактически реализовать это, или сделать это на уровне API, таком как ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта/экспорта в/из того, что для нескольких OODBMSs, будет отличным началом.
Данные часто живут дольше и важнее программы. Поэтому, даже если вы начнете разработку нового месторождения сегодня, вам нужно рассмотреть общую картину. Есть больше инструментов, процессов и опытных людей, работающих с системами RDBM. Подумайте о программе, о планировании емкости, интеллектуальном анализе данных, отчетности, ETL, интеграции с другими источниками данных и т.д. Как насчет того, чтобы ваша компания приобрела другую компанию и, таким образом, внесла все свои реляционные данные в вашу программу. РСУБД и связанные с ними инструменты настолько укоренились, доказаны и сильны, что я не вижу никакого стратегического смысла в использовании чего-либо еще. В какой-то небольшой нише возможно, но не в целом.
Базы данных объектов имеют очень хорошую нишу для проблем, таких как представление геометрии, например. CAD-систем, где графы объектов могут быть очень глубокими. Производительность JOIN быстро снижается примерно для 7 таблиц в большинстве реляционных систем, поэтому в САПР более эффективны самореферентные структуры в САПР.
Но важные приложения, такие как финансовые данные, поддаются реляционному представлению. Реляционная модель имеет прочную математическую основу, а SQL - успешный и популярный язык. Для финансовых учреждений, таких как банки, брокеры и страховые компании, нет стимула переключаться со СУРБД.
Для треугольных примеров OODB и RDB могут быть очень разными. Особенно, если вы работаете с небольшим количеством данных, которые вы можете тривиально прочитать все это в память сразу и записать все сразу. Но, в конечном итоге, OODB необходимо сохранить данные в очень подобном RDB формате - они не так уж отличаются.
Рассмотрим произвольный граф объектов, который может быть использован в приложении. На каждый объект могут ссылаться несколько других объектов. Когда вы сохраняете график объектов, вы не хотите сохранять объекты повторно каждый раз, когда они ссылаются. Во-первых, если бы у вас был какой-то цикл или самореклама, ваш метод save-object перешел бы в бесконечный цикл. Но в общем случае это пустая трата пространства. Вместо этого любой значительный хранилище данных должен объявлять уникальный идентификатор для каждого хранимого объекта (ключ, обычно суррогатный ключ в терминах РСУБД). Каждый другой объект, который ссылается на него, сохраняет тип и ключ объекта, он не сохраняет весь объект повторно. Итак, здесь мы воссоздали внешние ключи в нашем объектно-хранилище не RDB.
Затем сделайте вид, что мы хотим сохранить список объектов (A1, A2, A3...), связанных с другим объектом (B). Мы уже установили, что будем хранить ключи вместо того, чтобы дважды сохранять объекты. Но сохраняете ли вы ключи к объектам A1, A2, A3... на объекте B, или вы храните ключ в объекте B на A? Если вы сохраните их первым способом, и у вас есть все A, которые вы хотите, вы можете быстро захватить соответствующие B. Второй способ - обратное. Но в любом случае это односторонняя сделка. Если вы хотите запросить обратное тому, что вы сохранили, а ваши объекты хранятся в виде XML или JSON, это очень неэффективный синтаксический разбор по большинству нерелевантной информации, чтобы найти ключ в каждом файле. Не лучше ли хранить их в формате, где каждое поле было разделено, например столбцы в таблице?
В отношениях "многие ко многим" или в случае, когда вам нужно найти большое количество объектов в обоих направлениях, эта стратегия становится очень неэффективной. Единственное решение для исполнителя состоит в том, чтобы создать вспомогательный объект для хранения отношения с одним файлом для каждой связи, так что файл состоит из ключа A и ключа B, чтобы их можно было быстро найти. Мы только что заново изобрели таблицу перекрестных ссылок.
Таблицы с столбцами, уникальными идентификаторами (ключами), таблицами перекрестных ссылок... Это основные потребности для хранения объектов таким образом, чтобы их можно было эффективно извлекать. Хм... Это похоже на что-нибудь знакомое? Реляционная база данных обеспечивает именно эту функциональность. Кроме того, несколько поставщиков десятилетиями конкурировали за то, чтобы обеспечить самое быстрое хранение и извлечение данных с помощью лучших инструментов для резервного копирования, репликации, кластеризации, запросов и т.д. Это много для новой технологии, с которой можно конкурировать. И в конечном итоге я говорю, что СУБД в основном являются действительно хорошим решением проблемы эффективного хранения объектов.
Вот почему что-то вроде Hibernate существует - помещать объектно-ориентированный интерфейс в эффективную систему хранения RDBMS. Если вы видите, что другие типы хранилищ действительно светят, это разные проблемные области:
OODB не могут работать лучше, чем RDB, потому что они принципиально не отличаются.
RDB должны оставаться здесь, потому что сохранение больших графиков объектов таким образом, что они экономичны и экономичны для экономии времени и времени, а также отказоустойчивы и имеют определенную гарантию целостности данных, являются проблемой, с которой RDB были разработаны для решения первое место. Вот почему JPA и Hibernate также должны остаться, потому что они перекрывают разрыв между объектом и реляционными моделями данных. Объектная модель для упрощения манипуляций в памяти и реляционная для сохранения.
Словом Взаимодействие (большое слово в пятницу вечером <G> )
Большинство предприятий должны работать с устаревшими системами, работающими на РСУБД. Если они будут использовать OODBMS, им все равно потребуется доступ к РСУБД для определенных функций. Легче поддерживать один способ доступа к данным, чем два.
Когда у вас есть большие имена, такие как Oracle и SQL Server, в мире OODBMS и проверенная производительность в самых разных средах, THEN вы увидите больше проектов, использующих их.
Я думаю, что это случай
Если он не сломался, не меняйте его.
Реляционные базы данных чрезвычайно укоренились.