Cуществуют задачи, которые будучи изначально решены на базе классических ООСУБД (например, Versant FastObjects) будут на порядок быстрее ЛЮБЫХ решений с реляционными системами.

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

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

2)
А вот еще пример. Есть сеть связанных разнотипных объектов. Нужно добавить один элемент в эту сеть, полностью сохранив целостность хранимых данных. В таком случае при использовании реляционных СУБД нам прийдется вносить данные сразу во множество таблиц (информация о новом объекте и его связях), что будет сопровождаться многократными проверками для обеспечения целостности данных. В случае объектных СУБД такие проверки пройдут быстрее. Ровно та же ситуация будет и при необходимости поиска объекта в такой сети и т.п.

Приведенные мною примеры достаточно примитивны и, конечно, не отражают всей специфики реальных задач бизнеса. Но практика использования ООСУБД показывает, что они приживаются в таких сферах, как: управление телекоммуникационными сетями (хранение и всей информации о структуре и параметрах элементов сетей), биоинформатика (информация о сложных молекулярных цепочках и т.п.), системы прогнозирования и принятия решений (сложноструктурированная входная информация и варианты развития событий), промышленная автоматизация (управление сложными производственными линиями и цепочками).

Немаловажным фактором, способствующим повышению показателей быстродействия решений на базе ООСУБД является то, что сама объектная база может быть разделена на несколько частей и размещена на различных серверах (причем все связи между объектами сохраняются). Т.е. в этом случае легче реализовать распределенную обработку данных, чем в реляционных системах. И наконец, всегда надо понимать, что ООСУБД ориентированы на использование ОО языков при проектировании приложений. Именно поэтому ООСУБД более популярны у Java-разработчиков, чем скажем у .NET (где есть развитые средства интеграции с реляционными системами, которые во многих случаях по своему быстродействию вполне устраивают разработчиков). Именно использование грамотного ОО подхода позволяет строить очень быстрые системы на базе Java и ООСУБД (например, FastObjects или Versant Developer Suite).

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

www.fun4me.narod.ru>> ... приживаются в таких сферах, как: управление телекоммуникационными сетями

В таких сферах всё что угодно приживется... Но это ни о чём не говорит.

>> примеров использования ООСУБД крупнейшими западными компаниями множество

Западные компании всё что угодно использовать могут... Но это тоже ни о чём не говорит.

А чем таким так по вашему примечательны телекоммуникации? Я ведь, например, не утверждал, что ООСУБД прижились во всех сферах, где много денег. Например, в банковской сфере и бухгалтерии их применение в большинстве случаев не оправдано (впрочем, и здесь есть место - к примеру, в системах экспресс-анализа заемщиков при выдаче кредитов, каковые являются по сути системами прогнозирования и помощи при принятии решений).
Что же касается телекоммуникаций, то не стану говорить про все ныне существующие ООСУБД, а вот Versant VDS и FastObjects фактически появились именно в процессе реализации заказов телекоммуникационных компаний. И их применение в сложном оборудовании началось не вчера, а еще в самом начале 90-х.
Хотелось бы что-нибудь сказать по поводу России, но видимо основная причина отсутствия на наших просторах ООСУБД-решений проста. А где они, российские производители сложного телекоммуникационного (АТС, ATM-коммутаторы, GSM ... ) оборудования и сложных лабораторных комплексов для биологических исследований ? Ау-у ...

Впрочем сейчас ситуация меняется. Во-первых, появились компании (раньше их было совсем мало), которые пишут для крупных западных заказчиков и им уже в требованиях указывают на необходимость ориентации на конкретную платформу. А во-вторых, некоторые уже поняли, что мало сделать ОЧЕНЬ БОЛЬШУЮ и КРУТУЮ систему, но ее еще надо регулярно обновлять и развивать. Видал я оракловые базы с более чем 500 таблицами. Наверное те, кто это наворотил очень собой гордятся. Да вот только компании - обладатели такого богатства с ног сбиваются в поисках вундеркиндов, которые способны быстро войти в курс и заниматься развитием их систем (пусть даже они и хорошо задокументированы). И вот нарадовавшись досыта, начинают искать другие решения, позволяющие как быстрее и легче разрабатывать, так и обеспечивающие легкость внесения изменений в существующие системы уже в процессе эксплуатации, а также не требующие двухгодичного обучения сотрудников, которые потом захотят баснословные зарплаты.

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

Действительно лет 5-7 тому назад все это было проблемой для объектных СУБД. Но сегодня это НЕ ТАК. VDS и FastObjects в полной мере поддерживают и запросы (языки OQL, JDOQL и др.), и изолированные транзакции и многопользовательский многопотоковый доступ с возможностями блокировки на уровне объектов (сравните с блокировкой на уровне таблиц).

Что же касается отчетов, то и системы для генерации отчетов существуют полностью объекто-ориентированные (http://www.qint.de/), и ODBC-доступ к объектным базам из любых других систем генерации отчетности возможен.

В целом все зависит от специфики задачи и всех особенностей эксплуатации системы, рассматриваемых вкупе. Поэтому и нельзя привести ясный и простой пример из реальной жизни - граница, где применение объектных СУБД становится выгоднее, чем использование традиционных реляционных решений слишком расплывчата и зависит не только (я бы сказал, что это вообще не самый существенный фактор при принятии решений) от предполагаемого быстродействия системы, но от таких вещей как: требуемое время разработки, требуемая надежность, предполагаемый срок эксплуатации и частота внесения изменений и доработок, режимы работы системы, которые будут наиболее востребованы в процессе ее эксплуатации (ввод данных/генерация отчетов/групповые операции с данными и т.п.).

Чтобы меня не упрекали в отсутствии реальных примеров, привожу:
1) Borland CaliberRM (в Enterprise версии содержит встроенную базу данных Versant VDS).
2) MES-платформа автоматизации предприятий Siemens Simatic IT (Framewoek на базе Versant FastObjects).
3) Приложение Bosch Rubin NT для управления сетями безопасности (видеонаблюдение, пожарные/охранные датчики и т.п.) использует встроенный FastObjects.
4) Телекоммуникационное оборудование, в которое встраивается FastObjects:
управляющие контроллеры INTUITY AUDIX и DEFINITY, Lucent BCF 2000, GSM- и UMTS-контроллеры Ericsson и др.
5) Лабораторное оборудование Applied Biosystems и MDS Sciex.
6) Системы управления телекоммуникационными сетями NEC INC-100MS, Siemens AccessIntegrator.

и многое, многое другое ...

tygra авторграница, где применение объектных СУБД становится выгоднее, чем использование традиционных реляционных решений слишком расплывчата и зависит не только (я бы сказал, что это вообще не самый существенный фактор при принятии решений) от предполагаемого быстродействия системы, но от таких вещей как: требуемое время разработки, требуемая надежность, предполагаемый срок эксплуатации и частота внесения изменений и доработок, режимы работы системы, которые будут наиболее востребованы в процессе ее эксплуатации (ввод данных/генерация отчетов/групповые операции с данными и т.п.).
Как эти вещи по вашему могут повлиять и в какую сторону? Если уж эти вещи влияют на выбор, то как?

-- Tygra's --

Ок. Начнем по порядку.

Требуемое время разработки.

Утверждаю, что систему высокой сложности, для которой разумным является использование объектно-ориентированного подхода (т.е. задача разбивается на относительно самостоятельные сущности - бизнес-объекты, используется UML-моделирование и разработка клиентских приложений на базе ОО языков программирования Java, C++, C#), можно значительно быстрее разработать с использованием инструментария ООСУБД (FastObjects или Versant Open Access). Замечу, что это не означает обязательного использования в качестве хранилища данных собственно объектной СУБД - с Open Access можно применять и Oracle и MS SQL и множество других систем (вот кстати, лишнее доказательство того, что ООСУБД и РСУБД - суть две стороны одной медали, поскольку объектные данные можно автоматически переформатировать в реляционные и положить в реляционную СУБД - про быстродействие пока умалчиваю).

Требуемая надежность.

Cовременные ООСУБД (особенно VDS) имеют тот же уровень надежности, что нам может обеспечить Oracle. Есть и поддержка репликации и систем высокой готовности и т.п. Так что в данном вопросе РСУБД и ООСУБД сегодня равны.

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

Если систему предполагается эксплуатировать долго и при этом постоянно дорабатывать с учетом новых требований и изменений предметной области, то ООСУБД типа VDS и FastObjects на порядок лучше любой известной мне РСУБД. Это вызвано тем, что в упомянутых мною ООСУБД изменения в объектной структуре и атрибутах хранимой информации осуществляются совершенно естественным образом (бери клас, меняй атрибуты класса, а все объекты автоматически переформатируются), более того есть поддержка версий объектов и слияния структур (т.е. была одна объектная структура, а из нее произошли две других, мы их взяли и снова слили, получив объектную структуру, обладающую свойствами обоих своих родителей). И все это может производиться на работающих базах без остановки сервисов.

Режимы работы системы, которые будут наиболее востребованы в процессе ее эксплуатации

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

AAronЕсли смотреть по профилю, то автор с компании www.softkey.ru, которая в частности занимается распространением FastObjects. Если посмотреть на стоимость процессорной лицензии (22К), можно найти и некий интерес автора.

Касаемо темы топика, все это замечательно. Вкусно и красиво. Но FastObjects - встраиваемая в приложение СУБД. Без выделенного сервера. Правильно? Таким образом к этой базе нельзя в любой момент подцепить внешнее приложение. Например, для анализа статистики.

Насчет распределенных вычислений. Промышленные РСУБД умеют работать в кластерных конфигурациях. Ну и много всего остального. Так что надо четко представлять границы применимости конкретно FastObjects.

Если посмотреть на сайт ww.softkey.ru то можно увидеть, что мы продаем и Oracle и MS SQL, а цена. к примеру, Oracle Database Enterprise Edition Processor License 48К. И я не стану скрывать, что имею интерес к продаже всего: Oracle, MS SQL, Versant FastObjects, Versant VDS и тысяч прочих продуктов, предлагаемых нами.

Касаемо темы:
FastObjects может как встраиваться в приложение, так и запускаться в качестве выделенного сервера. К нему можно подцепиться для анализа статистики, в т.ч. и через специальный ODBC-драйвер.
FastObjects может работать в кластерных конфигурациях.
И много всего остального.
Все сказанное справедливо и для Versant VDS.

Господа, все эти проблемы были решены 4-5 лет назад. Действительно во всех ныне доступных на русском языке книгах написано, что ООСУБД "недоделаны", т.е. "не могут", "не поддерживают" и т.п. Но эти книги были написаны в середине 90-х. С тех пор очень много воды утекло - нету этих проблем.

-----------наверно в системе с 500 классами разобраться проще

А если у вас и база данных и приложение для работы с ней (как оно обычно и бывает), а приложение вы пишете на Java или C++/C#?
Сначала вам прийдется разобраться с 500 таблицами и роли в структуре базы данных, а затем - милости прошу разбираться и с 500 классами в приложении, которое предназначено для работы с этой базой.
Так не легче ли создать одну модель из 500 классов и работать только с ней?

А кэшируют выбираемые данные они тоже на уровне строк?

А весь объект в одной строке одной таблицы размещается? Если это такой простой объект, то РСУБД лучше. А если это некая связанная сеть объектов? Т.е. в случае РСУБД лежат они в десятке таблиц. Каковы же тогда будут издержки сервера на блокировку всех этих записей?

www.fun4me.narod.ruООСУБД ориентированы на работу с данными на уровне объектов. Объект - это строка таблицы, грубо говоря. А РСУБД предоставляют доступ к данным на уровне столбцов, организованных в отношения. Доступ на уровне столбцов более гибок и работает быстрее, потому, как не надо тащить на клиента весь объект.

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

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

Если это основная задача приложения, то РСУБД лучше.
А если это только одна из множества задач, то просто пишите запрос на OQL:
select attr1, attr2 from Objects where [условие]
И получаете результат без необходимости тащить все объекты целиком.

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

Но вы же предложили задачу, в которой действительно не надо тащить на клиента весь объект.
По моему это вопрос правильного построения объектной модели. Ее именно и нужно строить так, чтобы в типовых задачах на клиенте нужен был весь объект, а если это невозможно, то действительно - такая задача не для объектных СУБД.

www.fun4me.narod.ruВ общем, почему в России эта вещь не приживётся:

1. Дорогая
2. Нет пиратских копий
3. Её не преподают в институтах
4. По ней нет книг
5. Для всех задач хватает РСУБД

Полностью согласен только с п.4.
Но это вполне исправимо и будет исправлено в обязательном порядке.

www.fun4me.narod.ru6. Нет промышленного стандарта
7. Нет более лёгких аналогов и возможности выбора и возможности перехода на другого производителя.

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

jimmersА кто и как понимает объекно-ориентированнную СУБД? Так сказать, критерий.

/topic/146505&pg=-1