Почему базы данных отношений более распространены, чем объектно-ориентированные базы данных?Почему OODBMS так широко распространена, как РСУБД?
Если парадигма объектно-ориентированного программирования настолько распространена, разве мы не должны видеть много OODBMS? Разве они не будут работать лучше, чем RDBMS + OR/M?
Одна из причин, по которой RDBMS сохранила популярность, заключается в том, что она была установлена технология, хорошо понята и имеет стандартный язык (SQL), поддерживаемый несколькими поставщиками. Он также имеет несколько хороших интерфейсов, таких как ODBC и JDBC, которые делают его очень удобным для общения на разных языках. Стабильный API является сильным фактором сохранения доминирующей технологии.
В отличие от этого, нет четкой модели для OODBMS, а также нет стандартного языка и нет стандартного API. Стандарт де-факто не существует, если у него есть ведущая реализация поставщика.
Концепция OODBMS может работать лучше, чем РСУБД + ОРМ. Это полностью зависит от реализации. Но верно и то, что OODBMS не решают тот же набор проблем, которые RDBMS хорошо решают. Некоторые задачи управления данными намного проще, если у вас есть ссылочная целостность и реляционные заголовки, введенные в действие решением управления данными. Эти функции отсутствуют в модели OODBMS (по крайней мере, до сих пор).
В блогах много шума, что реляционные базы данных устарели, но СУБД, тем не менее, являются лучшим универсальным решением для подавляющего большинства задач управления данными.
Я думаю, что это случай
Если он не сломался, не меняйте его.
Реляционные базы данных чрезвычайно укоренились.
Одним словом Interoperability (большое слово на пятницу вечером <G>)
Большинство предприятий должны работать с унаследованными системами, работающими на СУБД. Если они будут использовать OODBMS, им все равно потребуется доступ к РСУБД для определенных функций. Легче поддерживать один способ доступа к данным, чем два.
Когда у вас есть такие большие имена, как Oracle и SQL Server в мире OODBMS и доказанная производительность в самых разных средах, THEN вы увидите больше проектов, использующих их.
Данные часто живут дольше и важнее программы. Поэтому, даже если вы начнете разработку нового месторождения сегодня, вам нужно рассмотреть общую картину. Есть больше инструментов, процессов и опытных людей, работающих с системами RDBM. Подумайте о программе, о планировании емкости, интеллектуальном анализе данных, отчетности, ETL, интеграции с другими источниками данных и т. Д. Как насчет того, чтобы ваша компания приобрела другую компанию и, таким образом, внесла все свои реляционные данные в вашу программу. РСУБД и связанные с ними инструменты настолько укоренились, доказаны и сильны, что я не вижу никакого стратегического смысла в использовании чего-либо еще. В какой-то небольшой нише, может быть, но не в общем.
«Данные часто живут дольше и важнее программы». - аминь. Средние уровни приходят и уходят, но данные живут вечно. – duffymo
OODBMS не подразумевает привязку к определенному языку больше, чем СУБД, привязаны к хранимым процедурам, специфичным для реализации. –
В теории вы правы, но на практике есть несколько известных реализаций РСУБД, которые хорошо поддерживаются инструментами, обширной базой знаний и опытными людьми. Моя компания только что завершила корпоративное слияние, и мы импортировали данные из базы данных другой компании в нашу базу данных (с большим количеством преобразований, массивов данных и очистки). Обе компании использовали Oracle, и это сделало вещи проще, чем если бы другая компания использовала малоизвестную базу данных. – softveda
Базы данных объектов имеют очень хорошую нишу для проблем, таких как представление геометрии, например. CAD-систем, где графы объектов могут быть очень глубокими. Производительность JOIN быстро снижается примерно для 7 таблиц в большинстве реляционных систем, поэтому в САПР более эффективны глубокие самореферентные структуры в САПР объектов.
Но важные приложения, такие как финансовые данные, поддаются реляционному представлению. Реляционная модель имеет прочную математическую основу, а SQL - успешный и популярный язык. Для финансовых учреждений, таких как банки, брокеры и страховые компании, нет стимула переключаться со СУРБД.
Самая большая проблема, которую я видел, - это отсутствие стандартизации. В мире РСУБД вы можете получить довольно далеко от любой случайной базы данных, если знаете SQL. В основном они реализуют его с небольшими вариациями. Я не знаю ни одной существующей РСУБД, которая не выполняет SQL: вы почти можете использовать «RDBMS» и «SQL» взаимозаменяемо.
Ближайшей вещью для OODBMS является, возможно, OQL, что было полным провалом.
Ни одна база данных никогда не применяла ее. Я использовал довольно красивые коммерческие OODBMS пару лет назад, но (по состоянию на 2007 год или около того, и он был на основной версии 8 или 9), он даже не поддерживал запрос объекта по его названию. В руководстве было сказано, что эта часть OQL, с которой они еще не добрались, пока не дошла. (Я не уверен, но вы, возможно, смогли отказаться от обычного вызова, чтобы сделать это.)
Большинство баз данных объектов, которые я видел недавно, имеют интерфейсы на родном языке, а не язык запросов, такой как OQL. Система, которую я использовал, например, поддерживала (только!) Perl и VB, IIRC. Ограничение аудитории только несколькими языками (или принуждение их писать обертки, как мы это делали) - это не способ завоевать друзей.
Из-за этого конкуренции нет, поэтому нет простого плана резервного копирования. Если вы поместите свои данные в MS-SQL и Microsoft перестанет его поддерживать, вы можете, возможно, сбросить свои данные в Postgres и перенести свои запросы без особых проблем. (Это может быть много работы, если у вас много запросов, но я не сомневаюсь, что вы это сделаете. Это боль, но не техническая сложность.) Или Oracle, или MySQL, или многие другие, как коммерческие и бесплатно.
Нет такой вещи с OODBMS: если тот, который вы используете, взлетает вверх, или они берут его в направлении, которое вам не полезно, или вам не хватает ключевой функции, которая вам нужна, вы можете 'просто сбрасывайте свои данные в конкурирующие OODBMS и отправляйте свои запросы. Вместо этого вы говорите об изменении основной библиотеки и изменении массивной архитектуры. Настолько реалистично, что вы ограничены коммерческой OODBMS, которой вы действительно доверяете (можете назвать хотя бы один?), Или OODBMS с открытым исходным кодом, которым вы доверяете своей команде, чтобы поддерживать, когда все идет плохо.
Если это звучит как FUD, извините, я этого не хотел. Но я был там, и с точки зрения управления проектами я бы не стал возвращаться, хотя среда программирования может быть замечательной. Еще один способ подумать: посмотрите, как популярное функциональное программирование сегодня, несмотря на то, что это хорошая идея. OODBMS - это так, но хуже, потому что это не просто ваш код, а ваш код и ваши данные. Сегодня я бы с радостью начал крупный проект в Эрланге, но я все равно не стал бы использовать OODBMS.
Поставщики OODBMS: чтобы изменить это, вам необходимо make it easy to leave you for your competitors. Вы можете выкопать OQL и фактически реализовать это, или сделать это на уровне API, таком как ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта/экспорта в/из того, что для нескольких OODBMSs, станет отличным началом.
Для трехобразных примеров OODB и RDB могут быть разными. Особенно, если вы работаете с небольшим количеством данных, которые вы можете тривиально прочитать все это в память сразу и записать все сразу. Но, в конечном счете, потребность OODB в сохранении данных в формате с очень похожим на RDB - они не такие разные.
Рассмотрите произвольный граф объектов, которые могут быть использованы в приложении. На каждый объект могут ссылаться несколько других объектов.Когда вы сохраняете график объектов, вы не хотите сохранять объекты повторно каждый раз, когда они ссылаются. Во-первых, если бы у вас был какой-то цикл или самореклама, ваш метод save-object перешел бы в бесконечный цикл. Но в общем случае это пустая трата пространства. Вместо этого любой значительный хранилище данных должен объявлять уникальный идентификатор для каждого хранимого объекта (ключ, обычно суррогатный ключ в терминах РСУБД). Каждый другой объект, который ссылается на него, сохраняет тип и ключ объекта, он не сохраняет весь объект повторно. Итак, здесь мы воссоздали внешние ключи в нашем объектно-хранилище non 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 также должны остаться, потому что они перекрывают разрыв между объектом и реляционными моделями данных. Объектная модель для упрощения манипуляций в памяти и реляционная для сохранения.
«Если это не сломано, не меняйте его», это настолько глупо ... почему делает что-то лучше или быстрее развивает программное обеспечение. Мой последний компьютер не сломался, когда я его изменил, это было просто МЕДЛЕННО !!!!Стремление к лучшему, более эффективные решения - моя цель как разработчик. – billy