ppvrt пишет:
> Коррелированые запросы необходимо переносить в функцию по следующим
> причинам:
> 1. Появляется возможность повторного использования данного подзапроса
Есть кэши подрапросов и так, без вынесения. В смысле, данных.
Правда, не во всех СУБД.
> 2. Уменьшается громоздкость кода, а, значит, увеличивается
> удобочитаемость и лёгкость поддержки кода
Это -- не про SQL. SQL -- язык немодульный, его писать надо
чтобы быстрее работало, а не чтобы легче читать было.
> 3. Вызов функций, находящихся в запросе, выполняется в отдельных
> потоках. Что увеличивает производительность запроса.
Это так вот во всех СУБД, во всех подзапросах, да ?
А если у меня в СУБД нет ни потоков, ни функций нет ?
Речь про кореллированные подзапросы шла, да?
Тогда функция будет иметь аргументом как минимум одно
поле из главного запроса. Какой смысл тогда её вычислять
параллельно, если ДО её вызова надо получить строку
главного запроса и скормить её поле этой функции ?
В общем, функции как части запроса наоборот вредны.
Потому что без них запрос может быть трансформирован
оптимизатором как угодно, с сохранением логики.
Например, подзапросы могут выноситься из запроса (некореллированные),
превращаться в JOIN-ы (или наоборот). С функциями оптимизатор
такие трюки уже проделывать не будет. SQL — язык не
модульный, там чем больше покажешь оптимизатору, тем
потенциально лучше будет результат.
Posted via RSDN NNTP Server 2.1 beta
Насколько оптимально их использовать в своем коде? Я имею ввиду select * — плохо... лучше указывать явно столбцы, а с коррелированными подзапросами?
Ellin пишет:
> Насколько оптимально их использовать в своем коде? Я имею ввиду select *
> — плохо... лучше указывать явно столбцы,
Чем же это лучше ?
а с коррелированными подзапросами?
Зависит от поздапроса и запроса целиком.
Posted via RSDN NNTP Server 2.1 beta