Производительность VIEW по сравнению с оператором SQL

У меня есть запрос, который выглядит примерно так:

select <field list> 
from <table list>
where <join conditions>
and <condition list>
and PrimaryKey in (select PrimaryKey from <table list>
    where <join list> 
    and <condition list>)
and PrimaryKey not in (select PrimaryKey from <table list>
    where <join list>
    and <condition list>)

В запросах подвыборки есть несколько собственных подселевых запросов, которые я не показываю, чтобы не загромождать оператор.

Один из разработчиков моей команды считает, что представление будет лучше. Я не согласен с тем, что оператор SQL использует переменные, переданные программой (на основе идентификатора входа пользователя).

Существуют ли какие-либо жесткие и быстрые правила при использовании представления в сравнении с использованием инструкции SQL? Какие проблемы с производительностью возникают при выполнении собственных SQL-запросов по сравнению с обычными таблицами и представлениями. (Обратите внимание, что все соединения/условия не соответствуют индексированным столбцам, поэтому это не должно быть проблемой.)

EDIT для уточнения...

Вот запрос, с которым я работаю:

select obj_id
from object
where obj_id in( 
(select distinct(sec_id) 
        from security 
        where sec_type_id = 494
        and (
            (sec_usergroup_id = 3278 
            and sec_usergroup_type_id = 230)
            or
            (sec_usergroup_id in (select ug_gi_id 
            from user_group 
            where ug_ui_id = 3278)
            and sec_usergroup_type_id = 231)
        )
        and sec_obj_id in (
        select obj_id from object 
        where obj_ot_id in (select of_ot_id 
            from obj_form 
            left outer join obj_type 
            on ot_id = of_ot_id 
            where ot_app_id = 87
            and of_id in (select sec_obj_id 
                from security
                where sec_type_id = 493
                and (
                    (sec_usergroup_id = 3278 
                    and sec_usergroup_type_id = 230)
                    or
                    (sec_usergroup_id in (select ug_gi_id 
                        from user_group 
                        where ug_ui_id = 3278)
                    and sec_usergroup_type_id = 231)
                    )                
            )   
            and of_usage_type_id  = 131
        )
        )   
        )
)
or 
(obj_ot_id in (select of_ot_id 
        from obj_form
        left outer join obj_type 
        on ot_id = of_ot_id 
        where ot_app_id = 87
        and of_id in (select sec_obj_id 
            from security
            where sec_type_id = 493
            and (
                (sec_usergroup_id = 3278 
                and sec_usergroup_type_id = 230)
                or
                (sec_usergroup_id in (select ug_gi_id 
                    from user_group 
                    where ug_ui_id = 3278)
                and sec_usergroup_type_id = 231)
                )
        )
        and of_usage_type_id  = 131

    )
    and
    obj_id not in (select sec_obj_id 
        from security 
        where sec_type_id = 494)
)

Ответы

Ответ 1

В зависимости от поставщика базы данных, в общем случае выполнение запроса по представлению объединяет SQL, определенный в представлениях с предложениями предложения Where и предложения Order By, добавляемых к sql, который вы передаете против View, чтобы придумайте комбинированный полный SQL-запрос для выполнения. Затем он выполняется так, как если бы он сам передавался процессу запросов, поэтому не должно быть разницы.

Представления - это организационный инструмент, а не инструмент повышения производительности.

От Разрешение просмотра SQL Server

Когда оператор SQL ссылается на неиндексированное представление, парсер и запрос оптимизатор анализирует источник как оператора SQL и представления и затем разрешить их в один план выполнения. Существует не один план для оператора SQL и отдельной план для просмотра.

Ответ 2

Обычный (не индексы/материализованный). Представления - это просто псевдонимы; они не предлагают каких-либо преимуществ по производительности. Выбор из представления генерирует точно такой же план запроса, что и выбор непосредственно из таблицы.

Ответ 3

Отклонения в сторону, не являются ли избыточные предложения PrimaryKey AND? Если значение PrimaryKey является IN в списке, не будет ли он в другом списке? Я думаю, что сжатие этих двух статей в одном повысит производительность.