Функции против сложных объединений в SQL

Question

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

Дело 1:

SELECT 
*
FROM table1 t1
INNER JOIN table2 t2 ON t1.ID=t2.ID
INNER JOIN table2 t3 ON t2.ID=t3.ID
INNER JOIN table2 t4 ON t3.ID=t4.ID
INNER JOIN table2 t5 ON t4.ID=t5.ID
INNER JOIN table2 t6 ON t5.ID=t6.ID
INNER JOIN table2 t7 ON t6.ID=t7.ID

СЛУЧАЙ 2

SELECT *
FROM table1 t1
INNER JOIN udf_myFunc() udf ON udf.ID=t1.ID

Есть ли случаи, когда один метод имеет определенные преимущества?

Answer 1

Это зависит.

• Табличная функция с несколькими операторами является убийцей производительности по сравнению с объединением. Его нельзя развернуть и интегрировать в запрос. Особенно плохо при использовании в apply.
  Иногда, однако, это является преимуществом, потому что объединение, которое дает такие же результаты, является кошмаром.
• Хорошо работает встроенная табличная функция. Сервер может раскрутить его и интегрировать в запрос. Не будет никакой разницы в производительности, план выполнения будет таким же, как и для объединения.
  Так что это может быть хорошим вариантом для инкапсуляции некоторой логики без снижения производительности.
• Скалярная функция в основном хороша, за исключением случаев, когда оптимизатор запросов делает странные вещи и начинает вызывать его гораздо чаще, чем это должно быть на самом деле. В этой ситуации можно переписать такую ​​функцию как табличную функцию, которая возвращает одну строку с одним столбцом и объединяет ее в виде таблицы вместо использования значения в условии where.
  Но в остальном тоже хорошо.

Answer 2

Нет.

• Если вы хотите скрыть / управлять сложностью и разрешить повторное использование, используйте View
• Вы не получите увеличения производительности при использовании пользовательских функций в соединениях
• Возможно, вы захотите настроить индексированное представление - это может привести к повышению производительности
• UDF трудно организовать и управлять ими в MS SQL. Чрезмерное опора на них может быстро закончиться беспорядком UDF

Answer 3

Для удобства чтения # 1 лучше - понятно, что делает объект, даже если он более многословен.

Для повторного использования # 2 лучше - особенно если вы видите, что логика может меняться во многих вызовах, лучше изменить ее в одном месте.

Я полагаю, это зависит от ваших целей. Я обычно выбираю удобочитаемость, а не повторное использование.

Answer 4

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

Мне нравятся функции, когда вам нужно массировать определенную часть данных, но использовать одну из них, чтобы избежать объединений, - отвратительный способ обработки вещей.