Да будуще достаточно туманно.
ООСУБД претендовали на революцию, но прошло 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(Имф процедуры(....))