Насколько оптимально их использовать в своем коде? Я имею ввиду select * — плохо... лучше указывать явно столбцы, а с коррелированными подзапросами?

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

E>Насколько оптимально их использовать в своем коде? Я имею ввиду select * — плохо... лучше указывать явно столбцы, а с коррелированными подзапросами?

Думаю, что когда как. С одной стороны, часто коррелированные подзапросы переписываются оптимизатором запросов на более эффективные джоины, но возможно вы пользуетесь СУБД, которая это не умеет. С другой стороны, кореллированные подзапросы могут быть более легко-читаемыми, чем явно написанные джоины.

Ellin пишет:

> Насколько оптимально их использовать в своем коде? Я имею ввиду select *
> — плохо... лучше указывать явно столбцы,

Чем же это лучше ?

а с коррелированными подзапросами?

Зависит от поздапроса и запроса целиком.

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

E>Насколько оптимально их использовать в своем коде? Я имею ввиду select * — плохо... лучше указывать явно столбцы, а с коррелированными подзапросами?

Коррелированые запросы необходимо переносить в функцию по следующим причинам:
1. Появляется возможность повторного использования данного подзапроса
2. Уменьшается громоздкость кода, а, значит, увеличивается удобочитаемость и лёгкость поддержки кода
3. Вызов функций, находящихся в запросе, выполняется в отдельных потоках. Что увеличивает производительность запроса.

Таким образом, твой запрос примет вид:

select t.A, t.B..., dbo.f_GetFirstColumn(t.Id)
from TableName t

ppvrt пишет:

> Коррелированые запросы необходимо переносить в функцию по следующим
> причинам:
> 1. Появляется возможность повторного использования данного подзапроса

Есть кэши подрапросов и так, без вынесения. В смысле, данных.
Правда, не во всех СУБД.

> 2. Уменьшается громоздкость кода, а, значит, увеличивается
> удобочитаемость и лёгкость поддержки кода

Это -- не про SQL. SQL -- язык немодульный, его писать надо
чтобы быстрее работало, а не чтобы легче читать было.

> 3. Вызов функций, находящихся в запросе, выполняется в отдельных
> потоках. Что увеличивает производительность запроса.

Это так вот во всех СУБД, во всех подзапросах, да ?
А если у меня в СУБД нет ни потоков, ни функций нет ?
Речь про кореллированные подзапросы шла, да?
Тогда функция будет иметь аргументом как минимум одно
поле из главного запроса. Какой смысл тогда её вычислять
параллельно, если ДО её вызова надо получить строку
главного запроса и скормить её поле этой функции ?

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