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

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

shuklin
Одним из требований к приложению часто выдвигается - отсутствие plain INSERT, UPDATE & SELECT в программном коде. Работа должна вестись исключительно через SP.

Кем это выдвигается? Фамилии у них есть? SP - хранимые процедуры? И в хранимых процедурах запрещается DML? Звучит как новость. Раскройте эту мысль поподробнее, пожалуйста.

shuklin
Это приводит к инкапсуляции реляционной схемы БД и к полному отсутствию возможности сделать adhoc запрос.

Как это инкапсуляция схемы БД? Уточните что имеется в виду.

Вот одним из недостатков ООМД иногда называют нарушение принципа инкапсуляции из-за необходимости оптимизации запросов. Это есть. А вот инкапсуляция схемы БД, это что-то интересненькое, наверное.

shuklin
Выходит что промышленность отказалась от свойств РБД которые принято считать сильной сторонй РБД и слабой стороной ОБД ?

Кто может и отказался, а кто нет. Судя по стандартам, если от чего и отказались так это простоты. Да и то судя в основном по объему, а не содержанию.

shuklin
Да, если вы под DML предполагали использование EXEC (@SQL)

EXEC (@SQL) как, я понимаю, это использование внедренного SQL в другие языки, а DML - обыкновенно, собственно подъязык языка БД, обеспечивающий манипулирование данными. Т.е. не предполагал под DML использование EXEC (@SQL) , но предполагал использование SQL вообще.

Так я уточняю SP - это хранимые процедуры, которые выполняет СУБД (их вроде PSM называют) или средний уровень какой-то вне СУБД? Вот Вы пишите далее:
shuklin
промежуточный слой SP



Вы видите потерю преимуществ в отказе от использоваения EXEC (@SQL) в клиентских прилоджениях, поставляемых заказчику? Я не вижу. Более того,
у нас, например, есть система отчетов, позволяющая писать произвольные запросы, но и она сохраняет их на сервере. Т.е. клиет опять вызывает ХП.
Не говроя про другие проги. Это лучше и по трафику и по сопровождению.

Однако, всякие тулсы во всю используют EXEC (@SQL), потому что SQL может использоваться итерактивно, и это имеет значение при разработке.

Т.е. РСУБД в полной мере реализует идею БД - доступ к ней различных прог, различными способами. Просто EXEC (@SQL) полезен в одних случаях, но менее полезен в других. Так есть другие способы.
Не догоняю Вашу идею об утрате чего-то.


shuklin
Это позволяет относительно лего вносить изменеия в структуру таблиц не вызывая никаких изменений в приложении.

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

shuklin

Имеется в виду, что приложение работает с некоторой схемой данных, которая не соответсвует схеме таблиц в БД. Благодаря такой инкапсуляции появляется возможность менять структуру таблиц не проводя перекомпиляцию приложения.

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


shuklin
Так что и по этому тезису ООМД круче РМД ))

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

А если так подходить, то у РСУБД есть тада ХП, которые обладают вычислительной полнотой. У самого SQL появляются аналитические ф-ии - позволяющие значительно проще получать многие результаты навигационного плана.

shuklin
Хм. А для меня это скушные будни ))

У всех у нас есть свои скушные будни ))

shuklin
Да
...
Нет

Тада не понял Вашу мысль совсем. Какая разница как ХП выполняют SQL?
Все SQL на сервере. Более того, я Вам писал, а Вы не обратили внимание, что можно создавать adhoc, помещать на сервере и опять их будет выполнять ХП.
На что влияет синтаксис ХП кроме самого ХП, или модуля БД?

shuklin
Я тоже не вижу. В том то и тезис. adhoc 1 - не нужен. 2 - не используется в реальной жизни

Этот ответ был про то, что EXEC (@SQL) все таки выполняентся на клиенте поставляемом клиенту. На клиентьах же вообще, тем более всяких тулсов, админских, разработческих и прочих, он не так и плох. Нам же не всегда нужно запросы в БД запихивать.

С чего Вы взяли, что adhoc не нужен, если главная цель иметь возможность как можно легче и быстрей получить необходимую инфу?
Думаю, что нужен. У нас вообще система, например, предаставляет юзерам стряпать свои отчеты если хотят. Но они хранят их в БД - нет EXEC (@SQL), хотя это adhoc. Зависимости adhoc -> нет в общем случае.
Это я повторил, потому что Вы не ответили на это.
Када я разрабатываю сам SQL - все есть adhoc, но EXEC (@SQL) в тулсе мне лучше.
Еще как используется. При разработке все adhoc, да и сопровождении.
Неужели Вы хотели сказать - этого нет в ООМД, этого не надо?

shuklin
Это и есть инкапсуляция. Особенно, если запретить приложению производить новые виды SQL и разрешить это делать только в SP.

Так я понял, что EXEC (@SQL) плохо в SP (которые в SP) в промышленных? Или все-таки в некоторых клиентских прогах? Где?
Запрещять совсем не надо. Есть када надо, есть када нет. См. выше. Дело проектировщика.

shuklin
И вовсе не нужно шарахаться от ОО термина, если вдруг оказалось что РБД это тоже умеет. Это ведь хорошо, что в РБД инкапсуляция тоже есть )))

Ну при чем здесь хорошо или плохо, что она там в каком-то смысле есть или нет? Ведь мы еще должны не запутаться в терминах.

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

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

vadiminfo
Разница в том, как формируется SQL.

Все таки мне кажется Вы имеете в виду где он формируется. Раз не надо чтобы на клиенте.

vadiminfo
Клиент не формирует SQL - только вызывает некоторые SP которые являются интерфейсом к БД.

Хорошо. Раз это именно клиентские проги для оператора.

vadiminfo
Итак мы имеем в итоге эволюции РБД возврат к процедурному стилю программирования )) И это вызвано реалиями а не теориями ))

Ну Вы может и имеете. А у нас доступ к данным не процедурный. Вот если Вы исключите SQL при доступе к данным. А так ничего не изменилось. Он всегда откуда-то вызывался. Просто есть разные интерфейсы.

vadiminfo
В данном контексте интересен тезис о тенденции отказа от adhoc. Эта тенденция - реальность по крайней мере в некоторых системах. И продиктовано это имхо необходимостью реализовать инкапсуляцию и контракты к интерфейсам в РБД.

Им не надо они и не используют. Хотя как они разрабатывают. Или получают инфу, которая в БД есть, тока запросы заранее не написаны?

vadiminfo
Правильно ли я понял, что в вашей системе динамических отчетов не используется конструкция аналогичная EXEC (@SQL)? Я имею в виду в широком смысле.

Используется, када надо. Т.е. када запрос не известен на стадии копиляции ХП. Так Вы против EXEC (@SQL) в ХП. Вы меня запутали. Но динамический используется в таких же кончструкциях как и статистический.
Запрос формируется в зависимомти от параметорв клиентских прог, вызывающих ХП с сервера. Т.е. они пишу CALL(Имф процедуры(....))

shuklin
Важно что на клиенте нет SQL следовательно нет JOIN и следовательно от РМД осалась только МД а "Р" упало и пропало.

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

shuklin
Я говорю, что SP инкапсулируют стуктуру БД. и на уровне клиента adhoc не нужен.

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


shuklin
И ваш пример только доказал истинность данного тезиса. Вы тоже используете инкапсуляцию.

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

shuklin
Я писал что признаком ненужности adhoc является отсутствие на клиенте SQL запросов а-ля SELECT|INSERT|UPDATE

Т.е. Вы думаете, что юзера будут писать на клиенте EXEC(@SQL) када им нужен adhoc? А раз в клиентских прогах это делать не рекомендуется, то и они туда не полезут. Боюсь, что если в проге EXEC(@SQL) то, все равно туда не полезет. ХП налабать проще. Т.е. так и не догнал связь EXEC(@SQL) и adhoc.

shuklin
Вот и я говорю - не всегда нужно. ч.т.д. УРА! )))

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

shuklin
В мире РБД наметилась тенденция в отказе от adhoc.

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

женщина-программистка
Если, например, Cerebrum этого не умеет и у нее нет мат модели для этого, зачем тогда ее сравнивать с РСУБД.

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

shuklin
Мало того, методы к таблицам, или сериализация графа объектов в таблицы, мне, опять же нафиг не надо.

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

shuklin
В очень многих задачах не нужно никуда мигрировать. Windows forever , Unix must die )))))

Вы рассматриваете тока задачи с оганиченными системными требованиями? На интерпрайзные совсем забили? А раньше говорили о промышленных. Там Windows forever не проходит. Там участвуют разные наворочнные системы.

shuklin
Тьфу на того, кто скажет, что Cerebrum это РСУБД )))

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