Здравствуйте, VladD2, Вы писали:

VD>2. Это не стандартные расширения.

Стандартные. CTE, AFAIK, появился в SQL'99

VD>MS SQL это частное решение, а речь идет о SQL как о стандарте.
VD>К тому же MS SQL имеет массу других кривых решений появившихся сильно раньше и массу ограничений.

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

Здравствуйте, VGn, Вы писали:

P>>Но вот, что нет подобных функций, что возвращают Таблицы, как парамтризированные вьюхи...

VGn>http://www.akadia.com/services/ora_pipe_functions.html

VGn>выглядит императивно, но работает функционально.
VGn>Большой минус — оптимизатор запросов идёт лесом.

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

Здравствуйте, VGn, Вы писали:

P>>Но вот, что нет подобных функций, что возвращают Таблицы, как парамтризированные вьюхи...

VGn>http://www.akadia.com/services/ora_pipe_functions.html

VGn>выглядит императивно, но работает функционально.
VGn>Большой минус — оптимизатор запросов идёт лесом.

В том то и дело, что нафиг оно нужно без оптимизатора запросов? Ведь если использовать повсеместно, то скорость будет никакая...
Конечно, можно сделать так:

CREATE OR REPLACE TYPE myRecord 
AS OBJECT
(
  A   INT,
  B   DATE,
  C   VARCHAR2(25)
)

CREATE OR REPLACE TYPE myRecordType
   AS TABLE OF myRecord
   
create function test
  return myRecordType
  PIPELINED
  as
  begin
     for i in (select * from mytable)
     loop
         pipe row(myRecord(i.a+1, i.b-1, i.c||'!'));
     end loop;
     return;
  end;
  
-- А потом использовать:
SELECT * FROM TABLE(test());

Согласись, выглядит ужастно!

А у MS SQL, похоже, инлайн функции, возвращающие таблицу-результат запроса, могут быть параметризируемыми и позиционируются как хорошая замена вьюхам.
К сож. я не знаю как проверить как использует их оптимизатор.

Здравствуйте, VladD2, Вы писали:

VD>1. Это хреново выглядит и читается.
Ну... это лучше чем 2 и более подзапроса... я использовал и на самом деле несколько лучше становится для больших запросов, т.к. они становятся знгачительно полегче...
VD>2. Это не стандартные расширения.
стандартные, исключая только то, что у MS SQL используется для деревьев рекурсия, а у оракла CONNECT BY
VD>3. У Оракла нельзя зада параметры.
Эээ.. а где там и у MS SQL параметры?

VD>4. По уму функцию должно быть можно задать как локально (для пакета запросов), так и на уровне БД, так чтобы ее можно было использовать многкратно. Собственно второе тоже кое как реализовано во многих серверах, но опять же через зад автогеном и опять же это нестандартные расширения.
согласен.

VD>К тому же MS SQL имеет массу других кривых решений появившихся сильно раньше и массу ограничений.
+1

VD>Если бы в начале проектирования SQL-ы ввели бы синтаксис immutable-присвоения, фунции и if, то нужны в большинстве примочек, появившихся за эти годы в диалектах SQL-я, попросту не поднадобилось бы. Те же вьюхи были бы банальным частным случаем.
+1

Здравствуйте, Plague, Вы писали:

P>А у MS SQL, похоже, инлайн функции, возвращающие таблицу-результат запроса, могут быть параметризируемыми и позиционируются как хорошая замена вьюхам.
P>К сож. я не знаю как проверить как использует их оптимизатор.

Которые inline — использует, я проверял. А вот которые нет — испольует плохо. Даже если не-inline функция идентична inline во всем, кроме синтаксиса заголовка, план запросов отличается не в пользу первой.

Получается так, что если взять пакеты как в PL/SQL и инлайн функции как в T-SQL, то может получится отличная штука!
Ну, и вложенные функции в том числе... =)

Еще чего не хватает — это нормального понимания алиасов полей, т.е. они существую только для именования результатов полей и не учавствуют, например в order и having by...
Да и в самом списке было бы не плохо, типа:

select sum(a) sum_a, case when sum_a > 0 then 'больше' else 'меньше' end 
from foo
group by b
having by sum_a <> 0
order by sum_a

Здравствуйте, Plague, Вы писали:

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.
P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>Что думает по этому поводу народ?

Создай над сиквелом свою проблемную надстройку.
Как вариант, с помощью макроязыка.

Здравствуйте, s_tarassov, Вы писали:

_>Создай над сиквелом свою проблемную надстройку.
Зачастую не все так просто. Например, если писать под Оракл, думаю, чтоб не потерять всю силу и гибкость PL/SQL, то нужно генерировать код не в динамике, а скажем, предварительно написать приложение на некотором языке (MySuperPL/SQL и т.п. ), а потом компилировать в PL/SQL. Т.е., конечно, возможно только частичная перекомпиляция, только изменяемых вещей. Как выше сказали, что существующим реализациям чего-то, да не хватает...
В оракле есть пакеты, но нет "инлайн" функций и т.п. Нет достаточно гибкого описания взаимосвязи между таблицами, что могло бы повлиять на облегчение программирования (кста, такой шаг сделан в 1С, вроде, там язык запросов на уровне объектов, конечно, простоват, но тем не менее есть. Уберсложные запросы — хрен соберешь, но вот средней сложности и очевидные собирать в разы проще, имхо.).

_>Как вариант, с помощью макроязыка.
Ну... те проблемы, которые решает этот макроязык PL/SQL решает достаточно хорошо.
Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...

Здравствуйте, Plague, Вы писали:
_>>Как вариант, с помощью макроязыка.
P>Ну... те проблемы, которые решает этот макроязык PL/SQL решает достаточно хорошо.
Макроязык нужен, когда не хватает выразительных средств базового языка.
Если такой проблемы нет, значит — нет.

P>Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...
Например, вот эта проблема решается
P>В оракле есть пакеты, но нет "инлайн" функций

Здравствуйте, s_tarassov, Вы писали:

P>>Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...
_>Например, вот эта проблема решается
P>>В оракле есть пакеты, но нет "инлайн" функций

Разница в том, что SPM не встроен в Oracle, а значит будет пристуствовать статическая компиляция. Перекомпиляция каждый раз 1000 функций — дело не благодарное. Если же будет попытка в динамике собирать запросы и т.п. — пойдут лесом многие оптимизации Оракла, да и вообще от динамики только проблемы видел.

Здравствуйте, Plague, Вы писали:
P>>>Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...
_>>Например, вот эта проблема решается
P>>>В оракле есть пакеты, но нет "инлайн" функций
P>Разница в том, что SPM не встроен в Oracle, а значит будет пристуствовать статическая компиляция. Перекомпиляция каждый раз 1000 функций — дело не благодарное.

Не каждый раз, а только при изменении "инлайн"-функции