SQL Server: встроенное табличное значение UDF по сравнению со встроенным представлением

Правильно определенный TVF не вызовет никаких проблем. Вы найдете множество заявлений о проблемах с производительностью в интернированных взрывных TVF по сравнению с представлениями или временными таблицами и переменными. Чего обычно не понимают, так это того, что TVF ведет себя иначе, чем представление. Определение представления помещается в исходный запрос, а затем оптимизатор перестраивает дерево запроса по своему усмотрению (если только предложение NOEXPAND не используется в индексированных представлениях). TVF имеет другую семантику, и иногда, особенно при обновлении данных, это приводит к тому, что вывод TVF помещается в буфер для защиты от хэллоуина . Это помогает пометить функцию СОЗДАНИЕМ СХЕМЫ , см. Улучшение планов запросов с помощью опции SCHEMABINDING в UDF T-SQL .

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

Поскольку вам нужна строка SQL и вы можете не иметь возможности добавить представление или UDF в систему, вы можете использовать WITH ... AS, чтобы ограничить сложный запрос одним местом (По крайней мере, для этого утверждения.).

WITH complex(patientid, datetime, measure_id, value) AS
(Select... Complex Query)
SELECT patient_id
,        datetime
,        m1.value AS physician_name
,        m2.value AS blood_type
,        m3.value AS rh  
FROM patient_table
INNER JOIN (Select ,,,, From complex WHERE measure_id=1) m1...
INNER JOIN (Select ,,,, From complex WHERE measure_id=2) m2...
LEFT OUTER JOIN (Select ,,,, From complex WHERE measure_id=3) m3...

У вас также есть третий вариант; традиционный ВИД (при условии, что у вас есть ключ для присоединения). Теоретически не должно быть разницы в производительности между тремя вариантами, потому что SQL Server должен соответствующим образом оценивать и оптимизировать планы. Реальность такова, что иногда это происходит не так хорошо, как хотелось бы.

Преимущество традиционного представления состоит в том, что вы можете сделать его индексированным представлением и дать SQL Server еще одно повышение производительности; однако вам просто нужно протестировать и посмотреть.

Ответ Sql Server 2005: Вы можете уменьшить встроенное представление, используя таблицы temp / var. Проблемы с производительностью - это временные вставки, которые вам нужны для каждого обращения к запросу, но если наборы результатов достаточно малы, они могут помочь. вы можете использовать первичные ключи в таблицах var и первичные ключи / индексы во временных таблицах. Помимо обычного, верю, я нашел пару статей, в которых говорится, что обе таблицы temp / var хранятся в temp db.

Функции UDF, как мы обнаружили, менее производительны, когда у вас есть многослойные udf в сложных запросах, но сохранит удобство использования. Убедитесь, что функция создана правильно для различных указанных условий. Те, которые БУДУТ использоваться для внутренних соединений, и те, которые будут использоваться для левых соединений.

Итак, в общем. Мы действительно используем UDF, но когда мы обнаруживаем, что производительность снижается, мы перемещаем запрос, чтобы вставить выбор UDF в таблицы temp / var и присоединиться к ним.

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

РЕДАКТИРОВАТЬ:

Если вам необходимо запустить это для кристалла, и вы планируете использовать хранимые процедуры, да, вы можете выполнять инструкции sql внутри SP для таблиц temp / var.

Позвольте мне знать, собираетесь ли вы использовать SP. Sql затем также кэширует планы sp с заданными параметрами по мере необходимости.

Также из предыдущего опыта с кристаллом, чего следует избегать, это группировка в Crystal, которая может быть выполнена в SP, номера страниц, если они не требуются. и вызовы функций, если это можно обработать на сервере.