Alexey Rovdo
Объектно-реляционная, разумеется.
А точнее можно сказать, что это реляционная СУБД с объектными расширениями.

Но это и есть те расширения РМД, которые получили название объектно-реляционная МД. Т.е. это одно и тоже. Все добавления чего-либо в базовую РМД носили названия расширенная РМД. Поддержку ООП стали называь ОРМД. А сейчас появился термин - универсальный сервер. Некоторые в наличие в Оракле вложенных таблиц усмотрели элементы сетевой модели.
Поддержка ООП в Оракле наращивается от версии к версии. Например, в 8 не было наследования, а в оно появилось (некоторые, вроде, считают что в БД наследование не нужно).
Кроме поддержки ООП в Оракле есть библиотеки для некоторых задач, например, геометрических задач, ГИС в 9. В 8 для этого еще использовались реляционные решения. Эти решения тоже развиваются

Alexey Rovdo

Cache - тоже объектно-реляционная, но уже ни в коем разе не реляционная с объектными расширениями.

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

Alexey Rovdo
Возможно относить Cache к иерархической СУБД и более правильно, чем к ОРСУБД, но вот кашисты с этим наверняка не согласятся. Они предпочитают совершенно бессодержательный термин "постреляционная".

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

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

Alexey Rovdo
Уж если как-то охота называть, то ОРСУБД или иерархическая СУБД

Т.е. Вы думаете, что все где есть ООП, но оно не ООСУБД, то оно тада ОРСУБД? Так или иначе из Ваших постов не понятно откуда там буква "Р" нарисовалась.
Вы впрямь думаете, что если Вы кешистам скажите, что это ОРСУБД, они с этим согласятся? То что с этим согласятся реляционщики, я сомневаюсь. Или там все-таки есть РМД?

Alexey Rovdo
возражаете против применения всех наиболее близко отражающих реальность названий (иерархическая или объектно-реляционная).

Если она ОРМД то, это серьезное заявление.

Alexey Rovdo
Я же еще раз скажу, что Cache не является ООСУБД. И вот уже эту свою точку зрения могу пояснить, если есть возражения.

Возражений нет, но поясните, если Вас не затруднит. Потому что это важно знать.

SergSuper

блин, неужели вам не всё равно как это называется?

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

mod
Оракл стопудовая реляционная СУБД, объкты в ней есть для удобства (ну или как дань времени)

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

2mod
Их пик 1989-1991 наскока я слышал. И они сыроваты все еще? Я про ООСУБД. И конкретно ожидалось, что ведущие производители перейдут на нее. IBM, например, поддерживает как минимум два типа СУБД - иерархическую (IMS) и РСУБД (возможно ОРСУБД) DB2. Ей стал быть не слабо было и ООСУБД слабать.
Потому причины "проще улучшить РСУБД, доработав до ОРСУБД" могут работать, тока если у ООСУБД нет ничего такого, чтобы затмить эту причину.
Думаю, что все гораздо сложнее. Там вообще проводят исследования. Тем более РСУБД (RSystem) появилась там как исследовательская. Думаю там исследовали возможности ООСУБД и не так как мы здесь на форуме.

ModelR
Это SQL - PL/SQL - Java - XML крокодиL

Объектные типы. В 9 поддержка наследования для них. ОО решения для задач типа ГИС в 9. От простого к сложному. Это же нужно в основном для специализированных приложений. На типовых пока РСУБД достаточно успешна.

ModelR
Однако назвать ее объектной что-то язык не поворачивается.

Ну, возможно, нужно тренировать язык на верткость - у многих это легко получается.

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

Скорее это главная особенность ассемблера. ООСУБД претендует на нечто большее, например, улучшенное моделирование. Ну и есно ОРСУБД тоже - это ответ на вызов ООСУБД.

mod
На самом деле коммерческие ООСУБД стали появлятся недавно. До этого были тока научные эксперименты...

Здесь говорят, что теории нет и судя по всему, нет ничего такого чем должны бы кончиться научные эксперименты. Стал быть эксперименты кончились ничем, и тада без всякой науки решили коммерчискме продукты лабать?
Тут говорили, что Версант вроде 15 лет на рынке. Читал, да и здесь вролде говорили, что многие специалисты сегодня думают, что у них относительно небольшой круг задач для применения. Но мож завтра что изменится?

mod
ООП то во второй половине 80-х тока стало развиваться.

Да но она появилась в рамках общего развития языков. Там она на своем месте. Действительно, там пришли к структурированному программированию. Оно хорошо структурирует код, но плохо данные. В ответ на это появились языки с поддержкой абстрактного типа данных, например, АДА. Они структурируют данные, но плохо код. Из всего этого как естественный ход появился ООП, который претендует на хорошее структурирование данных и кода. Но БД - другое дело. Там данные структурированы. Есть понятие модели данных, там есть и средства манипулирования данными. И теперь ООП должно превзойти все это. Это другая задача, чем превзойти подходы, которые либо вообще не структурируют данные, либо тока их. А оно еще, возможно, тащит за собой что-то лишние для БД из универсальных языков. Вон в соседнем топике выяснилось, что там типа навигация проникла даже в деклартивного типа систему запросов. Так что же Вы тада хотите?


mod
Да и есть ещё одна проблема: большинство существующих баз в реляционной модели выполнены. а это дело трудно перевести в объектную модель....

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

shuklin
На самом деле это недостаток РМД. Причем для РМД это фатальный недостаток. Отсутствие смелых решений приведет в итоге к застою и деградации.

Если это недостаток, то надо еще знать в чем он проявляется. Что толку от смелых решений, если они мало что решают? Нужен еще один доктор Кодд, а может и другие предпосылки для прорыва. Революции не все что-то дают, а разруху по началу многие гарантируют.

shuklin
Ващето это достоинство. Но производителей РБД понять можно - жалко ведь многомиллионные инвестиции выкидывать.

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

shuklin
Предпосылки есть и весьма серьезные. Про некоторые из них можно здесь прочесть: http://www.membrana.ru/articles/readers/2005/09/02/200800.html

Бегло просмотрел эти предпосылки. Они уступают известным недостаткам РМД из литры. Так шо Вы зря тратили время. Тем более Вы там, наскока, я понял высказали мысль о том, что и СУБД не так важна. Это все остальное просто перечеркивает. Уберите и побыстрее это из Вашего текста - мой Вам совет. Впрочем, мож я не правильно понял, особо не вникал. И опять запутали ситуацию искуствееным интелектом. Это шаг в сторону БЗ. Там уже не до сравнения ООСУБД и РСУБД - там СУБЗ. И само по себе ООП без еще чего-то там ничему помочь не может. Оно структурированием данных пока тока занимается. А там знания.
Проблема в том, где и как проявятся эти и другие недостатки РМД. Ить они во многих случаях не пороявляются. Зато достоинства и весьма ощутимые проявляются. Я думаю, что ООСУБД в таком виде как сейчас не совсем альтернатива РМД. Должно быть что-то посерьезней. А для тех приложений где у РМД проблемы, и где ООСУБД казалось бы есть перспектива, подготовлен ответ в виде ОРСУБД. Тоже, возможно, не без недостатков, но все же.

shuklin
Совершенно очевидно, что в пределах следующего десятилетия революции в этой области не избежать. Остается либо засунуть голову в песок и твердить про приемущества эволюции либо готовиться к переменам.

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

Там речь шла о проблеме для ООСУБД - конкуренция со стороны РМД с учетом наличия у последней многих уже успешных решений.
Но это тока одна из проблем. Другая то, что не ясно что есть у ООСУБД, чтобы быть лучшей во многих задачах. Что в типовых она лучше - мало кто верит. А ясного очевидного не видно. В специализированных, где у РМД трудности есть ответ от РМД в виде расширения ОРСУБД. Вот примерно о чем шла речь.
mod верит, что причина задержки ООСУБД на старте тока в первой проблеме, я что дело во всей совокупности проблем.

Hoar Frost
Если не нравится больше маркетинговый, нежели технический, термин "Постреляционная",

Этот термин на сегодня означает что СУБД либо ООСУБД либо ОРСУБД, поскоку все остальные, если не реляционные, то нужно выяснять почему они не дореляционные.

Hoar Frost
используйте термин Гибридная -

Ну, есть термин универсальный сервер. По-моему, Скуль и Оракл иногда тоже так называют.

Hoar Frost
тут мы также считаем, что к этому классу следует относить реляционные СУБД с объектными надстройками.

Термин "надстройки" нуждается в уточнении.

Hoar Frost
Но плюс к ним есть еще и прямой доступ к хранимым массивам - вот вам иерархический(многомерный, если хотите доступ).

Иерархические - дореляционные.

Если
Hoar Frost
В Cache есть объектный способ представления данных

То почему
Hoar Frost
В Cache есть объектный способ представления данных

?
Ведь именно это делало бы термин "Постреляционные" не только маркетинговым термином.

Hoar Frost
Куда будем классифицировать?

Очень бы хотелось как-то классифицировать. Но принципиально важно понять почему она не ООСУБД. Допустим кто-то говорит, что она ООСУБД. Что на это можно ответить?

Hoar Frost
Я отношу Оракл к Реляционным СУБД с объектной надстройкой - так будет корректнее всего.

Надстройка - не совсем ясный термин. В литературе по отношению к Ораклу и всем таким используют термин ОО - расширение = ОРСУБД. Т.е. РМД и раньше расширялась. Вначале поддержка ОО называлась просто очередным расширением РМД, а потом стала называться ОРСУБД.
Оракл поддерживает оба - колонки типа Объектного Типа (т.е. наряду со встроенными типами и Объектные типы) и Объектные таблицы - можество объектов похоже на организацию объектов в ООСУБД, но там коллекции, а тут множества (отношения). Впрочем и коллекции у Оракла тоже есть (правда, одномерные). Вопрос пока в основном в том как в какой версии поддерживаются Наследование, Инкапсуляция, Полиморфизм. Ну мож и другие какие отличия от сегодняшних представлений об ООП. Например "Интерфесов" нет, но и предок, по-моему тока 1 в Оракле 10.1.

Alexey Rovdo
По поводу ОО и ОР хорошо объяснено здесь.

Вы думаете там хорошо объяснено? Там речь о "сближении" моделей SQL и ODMG. И найдены какие-то отличия. На основании этого произведена критика ОРСУБД.
Разве этого достаточно? Разве ODMG официально признан идеалом, с которым следут тока сближаться? Это не очевидно. Обыкновенно достоинства и недостатки смотрят сравнивая подходы, например, поддержку наследования, инкапсуляцию, впрочем и OID, связей и т.д. И их известно больше чем в этой статье.
Однако, кое-что интересное, над чем можно подумать там, мне кажется, есть.

Alexey Rovdo
Мне казалось, что после прочтения данной статьи вы наконец перестанете задаваться вопросом "... принципиально важно понять почему она не ООСУБД" (в отношении любой СУБД).

Ответа про Кэш, в частности, у меня нет. И какие аргументы можно привести тем кто его считает за ООСУБД я пока не знаю (но хотел бы знать). При этом не изучая самого Кэша. Если бы все его считали ООСУБД, у меня вопроса бы не было. Например, про Версант я таким вопросом не задаюсь. То что Кеша не относят к ОРСУБД я знаю. Наскока я понял, Вы отнесли по принципу плохая ООСУБД = ОРСУБД. Но в этом принципе не просматриваятся "Р", ни то что ОРСУБД плохая или любая другая ООСУБД. Потому к ОРСУБД относить его пока рано. Даже РСУБД если что там есть - нужно подтверждать. Есть все-таки 12 правил Кодда - не так просто быть РСУБД на самом деле.
Поэтому мне эта статья в этом плане, к сожалению, не помогла. Я никада равенства между ООСУБД и ОРСУБД не ставил, так как считал их конкурентами. Поэтому идею в статье про "сближение" не очень пока воспринял.

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

Ничего не имею против. Тока не знаю зачем ОРСУБД надо становиться ООСУБД. Им не надо переставать быть "Р". Я то допускаю, что они лучше ООСУБД (благодаря "Р"). Я же реляционщик, потому не идеализирую ООСУБД как некоея совершенство, к которому надо стремиться. Для меня все выглядит так - РСУБД очень хороша во многих задачах. На некоторых плоха. В ООП есть рациональное. Его надо взять для расширения РМД для тех "плохих задач".
Однако, я отдаю себе отчет, что возможно я ошибаюсь. Потому интересуюсь по возможности и ООСУБД. И вообще всем, что так или иначе в литре упоминается как имеющее значение в области БД. Например, дореляционной ОМД коллеги ЧАЛа интересоваться вижу меньше смысла, чем иерархическими и сетевыми. Так последние как-то да упоминаются в серьезных источниках, хотя как устаревшие, но имеющие значение для истории.

Alexey Rovdo
А сегодня "ОР" - это простая возможность введения пользовательских типов (именно типов, а не классов в понимании ООП). Так, к примеру, реализация совершенно естественной операции "выбрать все объекты класса X" в сегодняшних ОРСУБД натыкается на массу проблем и ограничений.

Ну мы же говорим об эволюции. Совершенно очевидно, что ОРСУБД наращивают, т.е. не достигли предела. Потому что те "плохие" задачи еще не такая актуальность. Поэтому к сегодняшним ОРСУБД, возможно, нужно относиться как к прототипам реальных ОРСУБД.
В Оракле, думаю найти все объекты типа (а не класса) Х наверное будет и не такой уж массой проблем: 1 найти таблы содержащую тип X и обектные таблы такого типа из словаря БД. 2 выполнить к ним запросы. Ну, можно налабать PL/SQL блок, возможно, с динамическим запросом.
Найти все данные типа NUMBER того же класса задача.
Но не до конца ясна ее практическая ценность.
Однако, в ООСУБД вообще произвольные запросы, насколько я понял, не самое лучшее что там есть.

Alexey Rovdo
Какая же там идея про сближение, если ясно написано:


Вот в начале
"многими было воспринято как сближение "реляционной"1 и объектной2 моделей данных."

Но типа есть отличия и это плохо для ОРСУБД (а не для ООСУБД).

Alexey Rovdo
получаемые ОРСУБД никогда не смогут воспроизвести модель, поддерживаемую ООСУБД



Я то думаю, что не надо воспроизводить модель, поддерживаемую ООСУБД, т.е. модель ООМД. Например, помните, что там были проблемы с ОЦ? Этого не надо ни под каким видом ни в РМД, ни в ОРСУБД.

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

Alexey Rovdo
Нет таких задач, которые можно решать на РСУБД и нельзя решать на ООСУБД, равно как и наоборот. Вопрос в эффективности получаемых решений и трудоемкости их написания, и никакое "приближение" не может ни "подстраховать" ни повысить эффективность.

Ну, я имел в виду, что недостатки проявляются на некотоых задачах значительно и перевешивают достоинства.
При сравнении типов СУБД соотвественно по сравнению всех достоинств и недостатков для данной задачи. Это включает то, что Вы сказали про эффективность и прочее. Т.е. я это тоже имею в виду.
Там где РСУБД хороши - типовые приложения, их недостатки проявляются мало, зато достоинства значительно. Но есть типы приложений, где они не совсем адекватны. Вот за них в основном и идет конкуренция между ООСУБД и ОРСУБД. Конечно, есть конкуренция и на обычных типах приложений. Например, достоинством типа СУБД может быть наличие специалистов. Если они ОО специалисты, ну тада могут выбрать ООСУБД - это достоинство оказалось в данном случае сильным.
"Приближение" может "подстраховать" в том смысле, что другой способ вдруг окажется совсем плох, а ООСУБД хорошо. Тада приближение (типовые таблы) лучше заведомо плохого.
Alexey Rovdo
В таком контексте, сколько ни приближай "О" и "Р" - все остается по-прежнему - задачи, решаемые эффективнее на РСУБД, так и решаются, а задачи, решаемые эффективнее на ООСУБД, тоже там и остаются.

Я имел в виду то приближение, что в статье. Объектные таблы - множество объетов по сути. А в ООСУБД они в коллекции. В этом контексте приближение может иметь значение. Взято рациональное зерно. Причем не ясно, что обязательно лучше ОРСУБД с таким приближением или ООСУБД.

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

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

Вы верите, что ОРСУБД претендует тока на узкий класс задач где плохи и РСУБД и ООСУБД? На самом деле у них притензии на те задачи, где ООСУБД хороши. Их же продвигают ведущие производители СУБД не для узкого класса задач.
Про Кэша пока ниче понять не могу. Это для меня загадка.

Alexey Rovdo
Задайтесь вопросом, сколько реальных проектов сделано на Oracle с существенным использованием объектных расширений, входящих в эту СУБД. Когда вы соберете такую статистику, то думаю вопросов у вас не останется и ваше мнение об "ОР", как о мосте между мирами реляционных и объектно-ориентированных систем изменится ...

Ну, я же говорил, что думаю, что это все еще прототипы реальных ОРСУБД. Какая там может быть сегодня статистика?
Однако, в Оракле есть ОР - решения для ГИС. Причем от версии к версии они продвигаются. В 8 для этих задач предлагались еще Р решения. Это было совсем, наверное, далеко от реальных задач. ГИС - это пример "плохих" для РСУБД задач.
Причем Оракл всегда наровит и решения для упрощения разработки приложений кое-что налабать. Но сейчас ГИС на Оракле, наверное, еще тяжеловато для реальных больших задач.

Alexey Rovdo
С технической точки зрения (если выбирает профессионал, знакомый с техническими особенностями систем и предлагаемых ими моделей) выбор между ООСУБД и ОРСУБД затруднителен только в весьма редких задачах.

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

Alexey Rovdo
В конкретной задаче обычно все сразу ясно.

Если в смысле предыдущего абзаца, то да. А если объетивно, то выбор СУБД не считается чем-то простым.

Alexey Rovdo
Все производители всех СУБД продвигают свои детища для широкого класса задач.

Но не все имеют возможность втюхать при желании в свои детища, например, ООМД. Считаются, что ведущие производители это могут себе позволить, если увидят там что-то реально превосходящее их детищ.

Alexey Rovdo
Там есть и еще много чего. Только реальных работающих ГИС на основе именно этих решений я не встречал (тут надо понимать, что ГИС на основе Oracle я очень даже видел, но вот фирменными объектными расширениями такие продукты не пользовались, а работали на основе объектно-реляционного отображения).

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