Абстрактное о ЯП для СУБД

>> Разбирал sql-подобный запрос на языке, содержащем sql как подмножество, и делал из него чистый sql.

> Можно пример кода какого-нибудь, демонстрирующего мощь этого разрекламированного препроцессора? посмотри Oracle pro-C, pro-C++

>Дело не в плакатах. Победное шествие скриптовых языков.

Да нету никакого шествия скриптовых языков.

>Дело не в плакатах. Победное шествие скриптовых языков.

О каком-то шествии, тем более победном, можно будет говорить, когда Photoshop, MS Office или хотя бы на худой конец OpenOffice перепишут на Ruby или Pyхтоне. А до такого момента сам понимаешь, как до коммунизма в Малибу

>"почему существовавшие _языки программирования_ БД тихо сошли со сцены, уступив место _языку запросов_".

Ответ элементарен: существовашие языки программирования БД предполагали доступ к данным лишь с помощью приложения. Хороший, я бы даже сказал отличный пример этого подхода, Cronos Plus. А SQL позволяет оперировать данными из других приложений, из сторонних утилит а-ля SQL/Plus, Toad etc, и плавно заменять старое приложение более новым, не проводя обязательной конвертации данных из одной формы хранения в другую.

См. мой ответ про Лайтрум, написанный на Луа.

Где смотреть?

>Автоматы вполне себе заменяют объекты. Нужен rule-based язык описания автоматов, и их автоматическая генерация.

Когда конечные автоматы будут автоматически генериться с помощью rule-based языков описания автоматов, живые курящие жрущие и спящие программисты станут просто НЕ-НУЖ-НЫ. Ибо нужный потребителю код будет автоматически генерироваться в компьютере по заданным потребителем характеристикам, это ж коммунизм сразу настанет

http://www.lua.org/wshop05/Hamburg.pdf

>> Автоматы вполне себе заменяют объекты. Нужен rule-based язык описания автоматов, и их автоматическая генерация.

> Когда конечные автоматы будут автоматически генериться с помощью rule-based языков описания автоматов, живые курящие жрущие и спящие программисты станут просто НЕ-НУЖ-НЫ. Ибо нужный потребителю код будет автоматически генерироваться в компьютере по заданным потребителем характеристикам, это ж коммунизм сразу настанет

Ага, а браться эти rule-based описания будут через наконец-то допиленный libastral-ng? Или всё же их будет кто-то писать?

> существовашие языки программирования БД предполагали доступ к данным лишь с помощью приложения. Хороший, я бы даже сказал отличный пример этого подхода, Cronos Plus. А SQL позволяет оперировать данными из других приложений, из сторонних утилит

А я думаю, хост-языки оказались просто выразительнее специальных языков. Насчет доступа - по-моему, были языки, построенные над стандартным ODBC.

В Cronos Plus и подобных нету никакого доступа по ODBC.

> Дык о том и вопрос - почему всерьез никто не теоретизирует (ну или хочу ссылок на работы, если ошибаюсь)? Может, из абстрактной теории какой-то полезный выхлоп был бы, хоть минимальный. А такое ощущение, что поле просто покрыто мертвыми костями, а вдоль дороги мертвые с косами. И тишина.


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

Во-первых прогресс в языках доступа к данным всё-таки есть. Например есть X-Path, были и иерархические базы данных со специфическими возможностями. Но есть маленькое "но" - пипл это всё не хавает потому, что от языка доступа к данным всех этих фичей не требуется, а вот усложняют они жизнь преконкретно и работают при этом неэффективно.

В принципе все устаканились на использовании реляционных баз данных и на том, что SQL является необходимым и достаточным уровнем, эыыективно обеспечивающим доступ к данным.

Если вам нужен более высокий уровень абстракции - вперёд, есть куча имплементаций ORM. Я пока не услышал причину - почему ваш менеджмент не устраивает использование ORM на серверах приложений. Вы можете её назвать?

Вы можете сформулировать какую именно задачу вы пытаетесь решить и почему для её решения недостаточно широко распространённых технологий?

Я вот тут подумал, что по части "наворотов" над базовым функционалом, можно привести пример с Oracle. Вот вы упоминали execute immediate в начале треда. Что означает этот оператор? спользование этого оператора означает, что вы динамически формируете запрос к БД в соответствии с некими внешними условиями.
Теперь посмотрим как работает с этим Oracle. Для начала он разбирает запрос, проверяя синтаксис и выделяя сущности, к которым происходит обращение. После этого он отдаёт запрос оптимизатору, который анализирует параметры физической среды и состояния индексов запрошенных сущностей, формирует оптимальный план запроса. Это достаточно CPU-ёмкие операции, по этому результат обработки запроса кешируется в разделяемой памяти, что бы не производить разбор заново в случае аналогичной транзакции. После этого запрос исполняется, блоки даных и индексов считываются с диска, строки подходящие под условие возвращаются пользователю или апдейтятся в зависимости от запроса - в данном случае неважно.

Теперь клиент тестирует приложение на максимальную нагрузку и вдруг обнаруживает, что у него база валится с сообщением о том, что разделяемой памяти недостаточно для выполнения запроса. DBA лезет смотреть что там у него в SGA и обнаруживает кучу запросо
в типа:
select blablabla from TableName where name='vasyaPupkin1'
select blablabla from TableName where name='vasyaPupkin2'
select blablabla from TableName where name='vasyaPupkin3'
select blablabla from TableName where name='vasyaPupkin4'
И т.д. и т.п.
Тестовое приложение выстреливает тысячи таких запросов и это недалеко от номинальной загрузки, но база падает из-за исчерпания единстенного ресурса - объёма разделяемой памяти только потому, что все эти запросы - разные. Гигабайты разделяемой памяти исчерпаны.

Фикс простой - использовать binding variables типа:

select blablabla from TableName where name=:variableName

И всё.


--- после пяти попыток угадать капчу, сообщение оказалось слишком большим, продолжение ниже

.. продолжение:

Но, если согласно логики приложения вы вынуждены использовать execute immediate, - это означает, что вы делаете делаете _разные_ запросы, специфичные для каждой конкретной транзакции. И в этом случае у вас не будет простого фикса. Вам простопридётся резервировать сумасшедшие объёмы памяти на все случаи жизни. Это если вы используете БД, которая оптимизирует разбор запросов за счёт кеширования, если она не делает этого, то тормозить она будет в любом случае.

Т.е. для оптимального использования ресурсов, логика вашего приложения должна отображать его функционал в ограниченный набор типов запросов, при том, что БД ничего не знает о вашем приложении. Её работа обеспечивать целостность данных и максимально быстрый доступ к ним. А логикой приложения занимается, как всем нам известно, сервер приложений. Oracle предлагает своё решение, есть несколько свободных и коммерческих реализаций - выбор за вами, но вам от них никуда не деться - SQL это типа ассемблера для доступа к данным, всё остальное лежит уровнем выше и в конечном итоге _транслируется_ в теже самые SQL-запросы. Тем более, что SQL - относительно пререносимый язык, что особенно важно сегоднф на фоне кризиса. Кстати, я думаю, что ваши метания вызваны именно тем самым кризисом потому, что ваши менеджеры, ощущающие свою ненужность, занялись изысканиями в области велосипедостроительства и поиска каких-то уникальных чудо-технологий с целью подсадить на них компанию и стать "незаменимыми" сотрудниками. Потому, что в отличие от России, сокращать будут в первую очередь именно их - они же непосредственно продукта не производят, а жрут больше любого девелопера.. Я бы постарался просто держаться подальше от всех этих разборок сейчас..

Спасибо за развернутый ответ!

Если б вендоры типа Оракла однажды объявили, что SQL это асм, это было б почти честно, и я бы не создал этот тред. Но ведь они так не делают. Они продолжают делать вид, что PL/SQL это полноценный язык, который может быть основой полных решений (вплоть до интеграции с вебом). И причина одна - производительность. Всякий ORM тут же убивает производительность работы с БД, а иногда это неприемлемо. И если мы уж живем в мире, где люди хотят видеть код прямо внутри БД - может, пытаться как-то признать этот факт и пытаться развивать встроенные языки? Низкоуровневая механика, описанная Вами - да, оно так и есть, все верно. Но это что - боговдохновенная схема? Ее нельзя улучшить?

ЗЫ Про менеджеров все фигня, я впервые МНОГО писал на PL/SQL в 2000-2001, и уже тогда моя жабская и общепрограммистская сущность зверела от этого языка. Сейчас просто произошла смена заказчика, и тут опять приходится с этим воевать. Никаких менеджерских фантазий, банальный datawarehouse, dimensions, facts, staging areas, blah blah...

> И причина одна - производительность. Всякий ORM тут же убивает производительность работы с БД, а иногда это неприемлемо. И если мы уж живем в мире, где люди хотят видеть код прямо внутри БД - может, пытаться как-то признать этот факт и пытаться развивать встроенные языки? Низкоуровневая механика, описанная Вами - да, оно так и есть, все верно. Но это что - боговдохновенная схема? Ее нельзя улучшить? Это всё неправда :)

Цикл приложения: 0. пришла какая-то тразакция - смотрим в кеш. 1. Нашли - обработали. 2. Не нашли - полезли в базу. Пока база тащит нужные объекты - спим. 3. Пришли данные из базы - положили в кеш. 4. Go to (1)

Готовый load-balancing.

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

> ЗЫ Про менеджеров все фигня, я впервые МНОГО писал на PL/SQL в 2000-2001, и уже тогда моя жабская и общепрограммистская сущность зверела от этого языка. Сейчас просто произошла смена заказчика, и тут опять приходится с этим воевать. Никаких менеджерских фантазий, банальный datawarehouse, dimensions, facts, staging areas, blah blah...

Мне нравилось писать на PL/SQL, ничего озверевающего в нём нет. Что вы пишете "класс.метод" в джаве - точно так же вы пишете "пакет.функция" в pl/sql - в этом проблемы нет, проблемы с клиентской приблудой могут быть, в случае веб-приложения есть mod_owa, иначе же - это обычно самрописное приложение, т.е. пофигу. При этом пакеты персистентны в рамках сессии, если не сбрасывать их специально (что может оказаться дорогим удовольствием - как персистить кучу данных, так и реинициализировать состояние сессии).

Правда, реинжинирить это не приходилось.

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

В любом случае нужно смотреть что конкретно зхаказчику надо. Вряд ли там ТЗ сформулировано в стиле "как можно больше всего и можно без хлеба".

> Когда конечные автоматы будут автоматически генериться с помощью rule-based языков описания автоматов, живые курящие жрущие и спящие программисты станут просто НЕ-НУЖ-НЫ.

да уже и генерятся. Google "SWITCH-технология", google "КЛА Бусленко", google Ragel.

> это ж коммунизм сразу настанет

радио уже изобрели, а вселенского счастья так и не наступило. Сгенерированный автомат сам по себе -- это модель, её ещё надо специфицировать и донастроить до конечного результата. Тезис в том, что это -- проще.

> SQL это типа ассемблера для доступа к данным, всё остальное лежит уровнем выше и в конечном итоге _транслируется_ в теже самые SQL-запросы.

SQL уровнем чуть повыше ассемблера. Аналог "ассемблера для СУБД" -- это какой-нибудь MUMPS, на котором можно описать модель данных SQL, или модель данных ООБД или М-кубы. Так что уровней ещё больше.

> Если б вендоры типа Оракла однажды объявили, что SQL это асм, это было б почти честно, и я бы не создал этот тред. Но ведь они так не делают. Они продолжают делать вид, что PL/SQL это полноценный язык, который может быть основой полных решений (вплоть до интеграции с вебом). И причина одна - производительность

SQL скорее Си чем, асм. А PL/SQL -- препроцессор к Си или С++, emdebbed C-sql -- какой-нибудь Objective C.

> "SWITCH-технология", google "КЛА Бусленко", google Ragel

Не знаю про SWITCH и КЛА, но в Ragel нет вообще ничего нового (не говорю, что он не нужен).

> Нечего тут улучшать.
Почему? Почему нельзя группировать "похожие" запросы (как вот тот Ваш пример с васей пупкиным) и пытаться на этом сохранить память и процессорные тики? Ведь SQL же первым делом разпарсили, нашли внутреннее представление - почему ж не сделать маленький шажок, поискать в кеше "похожие" представления, это ж может в некоторых случаях даже улучшить производительность? Это даст возможность оптимизировать последовательность похожих execute immediate.

> Что вы пишете "класс.метод" в джаве - точно так же вы пишете "пакет.функция" в pl/sql - в этом проблемы нет
Ну не смешите пожалуйста. Язык, нечувствительный к регистру. Кроме того, за синтаксом класс.метод стоит объектная модель, а пакет.функция это только неймспейс, не более.

Я попробовал даже писать на PL/SQL в ОО стиле, на этом месте мне совсем захорошело;)

> В любом случае нужно смотреть что конкретно зхаказчику надо.
Оно конечно. Но если у заказчика есть IT департамент, который менеджит разработку, и который решил, что этот кусок будет делаться на PL/SQL по (список объективных и не очень соображений) - деваться с подлодки в общем-то некуда.

> PL/SQL -- препроцессор к Си
Да, вот на препроцессор оно похоже. Такое же тупое;)

> emdebbed C-sql -- какой-нибудь Objective C
Если б так... Хочется некоей общности синтаксиса, не обязательно 100% совместимости, но чтоб хотя б большая часть простейших конструкций была та же самая.

> Почему? Почему нельзя группировать "похожие" запросы (как вот тот Ваш пример с васей пупкиным) и пытаться на этом сохранить память и процессорные тики? > Ведь SQL же первым делом разпарсили, нашли внутреннее представление - почему ж не сделать маленький шажок, поискать в кеше "похожие" представления, это ж может в некоторых случаях даже улучшить производительность? Это даст возможность оптимизировать последовательность похожих execute immediate.

Не всё так просто.. Oracle примерно так и делает при CURSOR_SHARING=SIMILAR. Однако, что бы убедиться в том, что запросы похожи - их всё равно придётся поместить в разделяемую память и разобрать. И запросто окажется, что план исполнения запроса зависит значения переданной переменной. И это при том, что запросы идентичны. А вот тратить процессорные тики на задачи определения "похожести" разных запросов - выйдет намного дороже при том с тем же результатом: какие-то условия из найденных в запросе признаны unsafe, генерируем новый план. Нафиг не надо такого счастья :) Но. Если у вас запросы различаются только значениями параметров или вы можете привести задачу к этому - просто используйте биндинг переменных и не парьтесь.

> Ну не смешите пожалуйста. Язык, нечувствительный к регистру.

ну и что?

> Кроме того, за синтаксом класс.метод стоит объектная модель, а пакет.функция это только неймспейс, не более.

Аналогия такая: пакет - класс, функция - метод, переменная пакета - свойство класса, секция инициализации пакета - конструктор. Даже перегрузка методов имеется. Что не так? :)

> Я попробовал даже писать на PL/SQL в ОО стиле, на этом месте мне совсем захорошело;)

"в ОО стиле" - это создавая множество промежуточных почти ничего не делающих классов? :)

> Но если у заказчика есть IT департамент, который менеджит разработку, и который решил, что этот кусок будет делаться на PL/SQL по (список объективных и не очень соображений) - деваться с подлодки в общем-то некуда.

Тогда непонятен "искательский" дух треда, если средства реализации заданы изначально..

> А вот тратить процессорные тики на задачи определения "похожести" разных запросов - выйдет намного дороже
Пруфлинк хочу%) Кроме того, эта фича даст возможность использовать более динамичные языки, чем то что мы видим.

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

> ну и что?
Нечувствительность к регистру - это архинеудобно. Да и несовременно как-то;)

> Даже перегрузка методов имеется
Это как??? Научите. Какая может быть перегрузка без наследования?

> если средства реализации заданы изначально
Именно.

> Пруфлинк хочу%)

Нету пруфа. Это мои досужие измышления.

> Кроме того, эта фича даст возможность использовать более динамичные языки, чем то что мы видим.

Вот только задача СУБД заключается не в этом :)

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

У вас, наверное, и шелл с джавовским синтаксисом установлен?

> Нечувствительность к регистру - это архинеудобно. Да и несовременно как-то;)

Это из SQL. К тому же удобно при работе в консоли - меньше ошибок.

> Это как??? Научите. Какая может быть перегрузка без наследования?

http://www.google.ie/search?q=plsql+overloading