Вот, например у меня есть элемент запроса:



Внутри CASE стоит один и тот же запрос - типа ,если он возвращает отрицательное число, то столбец MMM должен равняться нулю, в противном случае он равнен числу, полученному в (SELECT ...)

Я не уверен, что SQL сервер догадается , что это один и тот же SELECT и не будет выполнять его дважды.

Но что мне сделать, чтоб этот SELECT упоминался в конструкции только один раз?
Мне ничего в голову не приходит.

(Хранимые процедуры не подходят - я как раз от них должен избавиться)

Это сообщение отредактировал(а) Zloxa - 16.3.2011, 17:38

Спасибо, работает ....

А что означает " s" в конце запроса?

(Без неё не работает)

алиас подзапроса


я тоже нахожу это абсурдным

Гм... почему? любой источник записей должен иметь имя. По-моему...

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

Это сообщение отредактировал(а) Zloxa - 16.3.2011, 18:35

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

Akina, не могу примпомнить, в MS SQL алиасинг столбцов обязателен? Помоему нет. Вернее в подзапросах -  да, в запросах - нет. Мне лично кажется что обязательный алиасинг столбцов куда более насущная необходимость нежели обязательный алиасинг подзапросов. Как обратиться с клиента к столбу select 3.14? 

Если честно, мне кажется, что ограничение, о котором мы гвоорим, сделано майкрософтом по причинам, отличным от эстетических или же идеологических.


Это сообщение отредактировал(а) Zloxa - 16.3.2011, 22:24

За себя могу сказать, что если бы не этот алиас, то я бы ,наверное, методом тыка нашел этот вариант решения ... но на все мои подобные попытки сервер выдавал непонятные ошибки ...
Ни за что бы не догадался, что надо обязательно алиас указывать.

Сейчас вот думаю над еще одним вариантом:



Здесь уже стоит не SELECT , а агрегатная функция SUM.
Но тут ,я думаю, сервер уже сможет догадаться и правильно оптимизировать  работу.

Наверное можно ничего не менять.

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

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