База скульная.
Есть многоэтажный запрос с временными таблицами.
Если параметр1 равен Ложь, то часть запросов нужна с пустым результатом, иначе с нормальным.

Пример:
Таб.поле1,
Таб.Поле...
Внутреннее Соединение РегистрСведениий.Паппап как Таб2
По (&Параметр1 = Истина)
И УсловияСоединенияТаблиц...

Скуль поймет оптимально, что при Параметр1=Ложь соединять, собственно, нечего? Или тупо будет соединять таблицы?

Не знаю как с соединениями, но в ГДЕ такую штуку оптимально понимает.

Так то тестил по времени, разница огромная, вроде скуль понимает....

такие запросы не сохраняются в кэше планов запросов.

и что мешает проверить : соберите статистику технологического журнала
с планом выполнения.

А смысл этого ?
Не проще ли вообще тело запроса править вместо того, чтобы параметр вводить ?

(3) в данной ситуации это мне и не нужно. Формирую запросом набор записей для регистра.

(4) смысл в том, что или писать три страницы кода с копроразбором текста запроса или так.

(6) Тогда пиши ГДЕ (&Параметр=Истина) и будет лучше.

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

Еще можно быть мужиком, юзать СКД с необязательными соединениями и просто не включать ненужные поля. Но это надо стальные яйцы

(8) дык если скуль понимает, то смысл дублировать и поддерживать разные тексты запросов?

(7) это скуль стопудово понимает и забивает на все соединения с таблицами?

Надо по ходу на форуме скульщиков такой ворос задавать...

Задал вопрос скульщикам.... вдруг, смеяться не будут :-)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1077939&msg=15579375

(11)
только не пишите, что 1с-ник. не уважают 1-ников тру прогерры.

(12)
для современных субд это равносильный запрос.

а для vs sql 2000 - 1 вариант предпочтительней

Ответили. Все нормально, скуль поймет :-)

(15)
и так очевидно что "поймет".
Вопрос , будет ли , зная параметры , строить план запроса с лишними соединениями. Я думаю - будет.

(16) думаю, что план запроса строить будет, т.к. указаны поля из соединяемой таблицы, но выбирать из таблицы строки не будет.

+(16) ну, и рассчитывать на то, что MSSQL будет всегда - это кагбэ не сильно правильно. Пусть даже сейчас и кажется, что так будет всегда

(18) так будет всегда :-)

(18)
конечно правильней обсуждать в рамках конкретных версий субд.

(20) вопрос волнует именно применительно к субд на скуле

(17)
будет.

как же не выбирать, соединять .

если заменить соединение на объединение, тогда может и не будет . нужно анализировать планы запроса

(22) план запроса - это итоговый запрос к бд, который генерит скуль на основе запроса разработчика?

(22) а что находится на уровне после плана запроса?

(22) имхо, не думаю, что двоичный код скуля будет тупо перебирать таблицу, не смотря на то, что результат известен заранее и равен ЛОЖЬ.
Скорее всего, запрос выберет имена соединяемых колонок и напишет в них Null

(23)
этому Вас должны были в институте научить.

wiki:%CF%EB%E0%ED_%E2%FB%EF%EE%EB%ED%E5%ED%E8%FF_%E7%E0%EF%F0%EE%F1%E0

и поисковыми системами интернет пользоваться.

Соединение отработает на "ура".
Основа для анализа и критики - суть запроса и её понимание.
Здесь автор явно в тупике.
--***
А то, что экзотика...
В сложных вещах и логика не проста.

(26) не все институты заканчивали, некоторые Родине служили, пока Родина в них нуждалась :-)

(27) почему тогда соединение с гигантской таблицей по условию параметра, равного ЛОЖЬ выполняется так же быстро, как если написать "Выбрать 0 как Поле"?

(29) Потому что там соединение с таким параметром вообще не выполняется, ИМХО. Тупо пустой результат возвращает.

Что такое "Выбрать 0 как Поле" я не понимаю, но если в условии применяется соединение не с "Внутреннее Соединение РегистрСведениий.Паппап как Таб2", а например, какой то ВТ, где записей, как раз 1, или со спец.регистром, с помощью которого нужно "размножить" записи запроса, то все "Ок".

(30) а колонки откуда берет?

Хотя тип колонки содержит в себе и Null тоже...

Думаю, что тупо выбираются имена и типы колонок соединяемой таблицы, не остальное скуль забивает.

SQL не может "забить" на INNER JOIN

(32) В (0) не вижу колонок из второй таблицы. Равно как и при соединении по параметру Истина, если в Выбрать не будет колонок из второй таблицы, то и соединении выполняться не будет.

(34) он и не забивает. Селектит имена колонок, типы и все... Наверно....

(0)замер производительности рулит

(35) представь, что они там есть. Если колонка указана в соединении, значит она есть.

INNER просто "отсечет" не удовлетворяющие записи. NULL выводит LEFT/RIGHT JOIN.

*Соединение.
(34) Чего это ? Утверждать не буду, но на левое забивает, если нет в Выбрать полей из второй таблицы.
(38) В условиях соединения, это не одно и тоже, что в Выбрать.

(39) сколько заплатишь если я сделаю null в одинесном внутреннем соединении?

Если сделаешь в "классике" то сколько угодно. Если будешь пытаться сделать по другому, например, объединениями, то и двух копеек не дам.
К слову, и в армии служили, и в институтах учились и Родина нас не забывает :)

(42) нас тоже родина не забывает, но военное образование далеко от гражданских институтов.... максимум бейсик раньше был :-)

И жесткий диск размером с целый зал :-)

(40) согласно определению из желтой книжки, у всех соединений принцип общий: две таблицы преобразовываются в третью, которая и есть результат.
Так что, с точки зрения двоичного кода, скулю монопенисуально, левое это или внутреннее соединение.

Не излечим.

(46) ты с желтой книжкой хочешь поспорить?

Дык допустимо такое в угоду удобоваримости и читабельности кода или грубое нарушение постулатов?

(36) Ну таки забивает, колонки берет из некоторой внутренней таблицы, в которой наверное просто поля и типы полей.

Select
    ДокШапкаРасчет.IDDOC as Док ,
    Ж.Date_Time_IDDOC
From
    dh7749 as ДокШапкаРасчет (nolock)
    inner join _1Sjourn as Ж (nolock)

        on (1=0)
            and
                (Ж.Date_Time_IDDOC between '20140101' and '20140131Z'
            and Ж.IDDOC = ДокШапкаРасчет.IDDOC)

В плане запроса просто Scanning an internal table of constants и select.

(49) Ура! Спасибо, ты не представляешь как я счастлив, что могу с чистой совестью писать такие запросы как в (0) :-)

(49)

условие константа  сравнение  константе (заранее известно на этапе анализа)
не равно

условию с переменная сравнивается с константой

(51) блин, это отменяет (50)?

(52)
проще всего проверить

соедините  таблицу с саму с собой 10-20 раз
по PK и условию аналогичному (12)

если выборок из соединяемых таблиц  не будет,
то скорость выборки 1 и 10 отличаться не будет.

(51) Мне таки кажется, что из 1С на скуль уйдет нечто подобное (49), так как подстановка  значения параметра (&Параметр1 = Истина)  произойдет при трансляции запроса в T-SQL.

(54) Если всё работает через Prepare-Execute, то сначала будет Prepare, где вместо параметра будет вопрос, а потом будет Set parameter и уже после этого Execute.
Вопрос в том - допрёт ли sql-server до того, что условие всегда ложно до сканирования таблицы или нет.