LEFT JOIN B ON @IncludeBJoin = 1 И B.AID = A.ID ГДЕ @IncludeBJoin = 0 ИЛИ B.ID НЕ НУЛЬ - PullRequest
0 голосов
/ 30 сентября 2011

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

SELECT
    ...
FROM
    A
LEFT JOIN 
    B ON 
    @IncludeBJoin = 1 AND
    B.AID = A.ID 
WHERE 
    @IncludeBJoin = 0 
    OR B.ID IS NOT NULL -- If included, only include INNER JOIN results

Цель вышеупомянутого состоит в том, чтобы замкнуть условно ненужное соединение с B, когда необходимы только результаты от A.Это простой случай, но в практическом случае было бы много таких необязательных объединений.Я хотел бы избежать отдельных хранимых процедур для каждой комбинации, если она стоит затрат на производительность.

Тогда как насчет этого расширения?

SELECT
    ...
FROM
    A
LEFT JOIN 
    B ON 
    @IncludeBJoin = 1 AND
    B.AID = A.ID 
WHERE 
    @IncludeBJoin = 0 
    OR B.ID IS NOT NULL
GROUP BY A... WITH ROLLUP                             -- Extension
HAVING (@AggregatesOnly = 0) OR (GROUPING(A...) = 1)  -- Extension

Цель вышеизложенного состоит в том, чтобы всегдавернуть свернутые агрегаты и при необходимости включить строки компонентов.Если @AggregatesOnly = 1, так что мне нужны только группировки, какую цену за производительность я бы заплатил?

Планы выполнения кажутся мне несколько волшебными, поскольку их представления могут показаться концептуально далекими от исходного определения оператора и внутреннего-работы механизма выполнения SQL не являются хорошо документированными публично AFAIK.Я читал, что процедурная логика, такая как использование операторов IF в хранимых процедурах, действительно может убить выгоду от скомпилированной хранимой процедуры.Имеют ли эти механизмы короткого замыкания тот же эффект, даже если они кажутся более «основанными на наборе»?

...