До меня тут доехало, что с введением CTE (common table expressions) язык SQL стал тьюринг-полным.
Вот несколько примеров:
--Генератор последовательности целых чисел:with recursive
gen (n) as (
select 1 from RDB$DATABASE
union all
select gen.n + 1 from gen
)
select n from gen
--Генератор последовательности Фибоначчи:with recursive
gen (n, fib1, fib2) as (
select 1, 1, 1 from RDB$DATABASE
union all
select gen.n + 1, gen.fib1 + gen.fib2, gen.fib1 from gen where n < :p
)
select n, fib2 as fib from gen
--Факториал:with recursive
gen (n, fact) as (
select 1, 1 from RDB$DATABASE
union all
select gen.n + 1, gen.fact * (gen.n + 1) from gen where n < :p
)
select n, fact from gen
where n = :p
Tonal- пишет:
> И с каких это пор полнота по Тьюрингу мешает декларативности? > Вон Prolog или Haskell тоже тьюринг полный и от этого они становятся > менее декларативными?
Думаю, что становятся. Ну да ладно, это теоретический спор.
> Сама конструкция CTE очень похожа на let/in из Haskell только более > ограничена (например запрещена взаимная рекурсия).
Без WITH ... CONNECT BY в SQL (чистом, без процедурных расширений)
нельзя было писать алгоритмы. Можно было только описывать данные,
которые ты хочешь получить. Теперь, с WITH — можно.
Здравствуйте, MasterZiv, Вы писали: >> SQL стал тьюринг-полным. MZ>И чему радуешься ? Теперь SQL стал не декларативным языком. MZ>Ну если конечно твоя любимая СУБД поддерживает это уродство.
И с каких это пор полнота по Тьюрингу мешает декларативности?
Вон Prolog или Haskell тоже тьюринг полный и от этого они становятся менее декларативными?
Сама конструкция CTE очень похожа на let/in из Haskell только более ограничена (например запрещена взаимная рекурсия).
Ну и насчёт того, зачем оно надо, вон шаблоны в С++ тоже поначалу использовались в основном для примитивных контейнеров, а сейчас это целое активно развивающееся направление метопрограммирования, серьёзно влияющее на развитие языка.
Plague пишет:
> WITH с рекурсией входит в стандарт SQL-2003.
Да я в общем в курсе. Да только кто этот стандарт поддерживает
в полном объеме ? (я знаю, что во многих СУБД сейчас есть WITH)
> Думаю, если что-то развивается, то значит это кому-то нужно.
Иногда за "развитием" скрывают кое-что другое. Имитацию
бурной деятельности, трату средств, получение преимуществ
в конкурентной борьбе ...
Мне, > конечно, не известно какого рода запросы Вы используете, но для > некоторых разрабатываемых нами отчетов запрос составляет несколько сотен > строк, из-за особенностей системы отчетов, т.е. по-сути собирает, > обрабатывает данные для отчета. CTE в разы упрощает ясность запроса, > позволяет стандартным и достаточно удобным способом использовать > древовидные структуры, в моем случае он упростил его в 3 раза. Т.е. за > счет повторного использования кода.
Я в общем за вас рад. А вот за SQL-2003 — не очень. Ну да ладно.
> На счет Представлений (VIEW) хочу сказать — удобства мало.
А при чём здесь это ? Разве была о них речь ?
Или вы так, к слову ?
> но сильно ухудшается его читабельность и возможности модификации, из-за > отсутствия повторного использования кода.
SQL и повторное использование кода — две вещи несовместные.
Как гений и злодейство. Кто тут гений, кто — злодейство, оставляю гадать вам.
> Мне интересно, для чего его вам хватает?
Мне его хватает для получения данных из базы данных, разумеется.
А также для реализации сложной бизнес-логики.
Здравствуйте, MasterZiv, Вы писали:
MZ>Tonal- пишет:
>> До меня тут доехало, что с введением CTE (common table expressions) язык >> SQL стал тьюринг-полным.
MZ>И чему радуешься ? Теперь SQL стал не декларативным языком. MZ>Ну если конечно твоя любимая СУБД поддерживает это уродство.
А еще поддерживает MS SQL Server, он и так не очень стройный! А это всего лишь подпорка, чтоб хоть как-то упростить работу с древовидными структурами, имхо.
Уже обсуждали, в Философии программирования SQL и что ему не хватает.
Здравствуйте, MasterZiv, Вы писали:
>> Уже обсуждали, в Философии программирования SQL и что ему не хватает. MZ>SQL-ю все хватает, его не надо использовать для того, для чего его не надо MZ>использовать.
Дополню: А использовать его надо для того, для чего его и надо использовать. И точка!
P.S. Интересно, а декларативность и полнота по Тьюрингу — это взаимоисключающие понятия?
Здравствуйте, MasterZiv, Вы писали:
MZ>SQL-ю все хватает, его не надо использовать для того, для чего его не надо MZ>использовать.
WITH с рекурсией входит в стандарт SQL-2003.
Думаю, если что-то развивается, то значит это кому-то нужно. Мне, конечно, не известно какого рода запросы Вы используете, но для некоторых разрабатываемых нами отчетов запрос составляет несколько сотен строк, из-за особенностей системы отчетов, т.е. по-сути собирает, обрабатывает данные для отчета. CTE в разы упрощает ясность запроса, позволяет стандартным и достаточно удобным способом использовать древовидные структуры, в моем случае он упростил его в 3 раза. Т.е. за счет повторного использования кода.
Я так понимаю, что SQL не надо использовать для достаточно сложных вещей, т.к. его читабельность и возможность легкой модификации запросов сильно снижается.
На счет Представлений (VIEW) хочу сказать — удобства мало. Варианта три:
1. Исползовать представления — упрощается запрос, но его скорость работы оставляет желать лучшего.
2. Использовать множество представлений разной сложности — слишком большое количество представлений сильно запутывает чтение запросов, ну и подбор требуемых представлений.
3. Не использовать представления — запрос начинает адекватно работать, но сильно ухудшается его читабельность и возможности модификации, из-за отсутствия повторного использования кода.
Мне интересно, для чего его вам хватает? Есть примеры, в которых люди придумывают язык более высокого уровня, который потом транслируется в SQL. Думаю не от множества свободного времени.
Здравствуйте, Tonal-, Вы писали:
T>До меня тут доехало, что с введением CTE (common table expressions) язык SQL стал тьюринг-полным. T>P.S. В примерах используется диалект Firebird 2.1
Портясающе! Очень интересно!
Коллега, а можно на SQL решить задачу размещения 8 ферзей?
Если можно, то не означает ли это, что технически возможно часть логики приложения реализовать на SQL? Понятно, что это врятли разумно, но возможно?
Простите за глупые вопросы, но я никогда ранее не сталкивался с SQL. Так ужсложилось
Здравствуйте, md03t4, Вы писали: T>>До меня тут доехало, что с введением CTE (common table expressions) язык SQL стал тьюринг-полным. M>Коллега, а можно на SQL решить задачу размещения 8 ферзей?
Да, как и любую другую вычислимую задачу.
M>Если можно, то не означает ли это, что технически возможно часть логики приложения реализовать на SQL? Понятно, что это врятли разумно, но возможно?
Как бы и сейчас выносят.
Во всех нормальых серверах есть языки для создания "триггеров" и "сохранёных процедур".
Обычно это императивные языки с уровнем примерно как у классического паскаля или бейсика.
Правда, в последнее время вместе с ними начяли использовать и классические языки: java в Oracle, семейство .Net в MSSQL, Java, Python, Lua, Ruby, Scheme и ещё несколько в PostgreSQL.
Другое дело, что это всё расширение конкретных серверов, не совместимые между собой.
M>Простите за глупые вопросы, но я никогда ранее не сталкивался с SQL. Так ужсложилось
Полюбопытствуй.
Здравствуйте, Tonal-, Вы писали:
T>Обычно это императивные языки с уровнем примерно как у классического паскаля или бейсика. T>Правда, в последнее время вместе с ними начяли использовать и классические языки: java в Oracle, семейство .Net в MSSQL, Java, Python, Lua, Ruby, Scheme и ещё несколько в PostgreSQL.
Да, про такие я читал. Но насколько я понимаю Ваши примеры — это не триггеры. Это обычные запросы которые не надо хранить на сервере, но можно там исполнять.
Здравствуйте, md03t4, Вы писали: M>Но насколько я понимаю Ваши примеры — это не триггеры. Это обычные запросы которые не надо хранить на сервере, но можно там исполнять.
Об том и речь.
Т.е. DML-ная часть SQL с введением CTE стала тьюринг-полной.
