украшаем запрос MS SQL
 

1. можно ли как-то запустить Query Analyzer (2000) с ярлычка, чтоб он не заново запускался, а создал окошко в уже открытом аналайзере? А то задолбал плодиться, я забываю смотреть, есть он в живых или нет.

2. есть уже заполненная табличка:
нужно оставить в ней записи, имеющие хотя бы одно пересечение с другими при одинаковой groupId. Остальные удалить. Я сделал, но мне кажтся чёто как-то некрасиво и медленно, через delete where not exists(...). Сами понимаете, некрасивые самолёты не летают. Есть варианты как причесать запрос?

для MS SQL есть свой раздел форума
2. сразу сделать правильную (необходимую) выборку. Временные таблицы - очень ресурсоёмкое решение, так ли они нужны в данном случае?

Можно тему туда перенести? Я не заметил раздела

Может я неправильно понимаю как оно работает, обрисую задачу:
Есть табличка с оплаченными повременными услугами, примерно миллион-два записей (с 2004 года). Из них нужно выбрать такие записи за последние 4 недели, которые бы оплачивали одну и ту же услугу в одно и то же время, то есть выяснить какие есть перекрытия оплат.
Табличка имеет много всяких полей, я выбрал только нужные 4 поля за последние недели (около 1000 строчек), а потом искал пересечения
А можно ли как-то создать временный view? чтобы съэкономить и упонятнить код

pva
1. Запускать скриптом, который проверяет наличие QA и либо запускает, либо активирует окно и отправляет комбинацию <Ctrl+N>

pva, я бы всё-таки работал с изначальной таблицей
где-то примерно так:
на выходе получаем список перекрытий
(в примере не понял соотношение dateIn и dateOut)

дело в том, что граница оказания услуг может быть и не кратна дню, пример:
услуга 1: от '2008-01-01 12:00:00' до '2008-01-02 14:00:00'
услуга 2: от '2008-01-01 18:00:00' до '2008-01-02 12:00:00'

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

Busla, Я приведу пример когда этот вариант не работает:
теперь из каких соображений я делал:
Насчёт выборки действительно ступил - заработался. Всё действиетльно можно одним несложным селектом сделать. На сегодня такой вариант:

pva, всё правильно. Ты просто забываешь, что помимо

не-а, не забываю :-P если список состоит только из этих двух записей, то твой вариант запроса выдаст только одну. А надо обе (это всё необходимо для отчёта, чтобы потом человек посмотел пересечения и принял решение, что из них поправить)

остаётся вопрос с временными view. Можно такие сделать? На сколько это критично к ресурсам? у меня услуги - это
Временные - это в том смысле, чтобы они уничтожались после выхода из блока, где были созданы, независимо от того успешно прошла операция или нет

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

AFAIK вьюхи интерпритируются примерно как макрос - т.е. хранится только код запроса, и он подставляется в другие запросы - содержимое view никак специально не индексируется, не кешируется и т.п.
Можно использовать не view, а подзапрос:

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

когда идентичные - это нормально, нужно обе выдавать. Вот теперь красиво получилось! Пасиба *DRINK*. Единственное, со знаком ">=" всё-таки надо строгое ограничение (без =), потому что если одна услуга заканчивается '2008-09-18 12:00' а другая начинается в это же время - это не пересечение

Можно, но права администратора БД-нужны, (что не правильно в приложении).

View, с точки зрения программиста - SQL-запрос/макрос хранимый на стороне сервера. С точки зрения видимости - таблица БД.
Т. е. этакая виртуальная динамическая таблица.
Т. к. View практически ничего не занимают, то смысла Создавать-Удалять их в процессе выполнения нет никакого.
Более того, с точки зрения структурирования и изоляции кода это глупость.

Хочу заметить, что связка нескольких View в одном запросе читабельнее чем один сложный запрос с join.

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

Поэтому и подумываю как бы тут view применить
Рассматриваем только данный конкретный случай: нужно сказать серверу что я собираюсь сделать 2 раза одинаковый запрос и соединить его. Оставлять view навека в базе не хочется. Всё-таки временную таблицу (declare @t1 table...) сделать?

А почему собственно? Они для этого и предназначены.

Временная таблица, ( т. е. та которая существует только во время сессии - я правильно вспомнил терминологию MS SQL? Давно не работал с ним.)
Тоже не плохой выход, особенно с точки зрения, работы с высоконагруженными базами.
Наверно, самый оптимальный случай особенно при очень сложных выборках.

С точки зрения блокировок, "монолитный" запрос это самое печальное.

на самом деле pva путает понятия временная локальная таблица и таблица-переменная. Он использует таблицу-переменную. Суть, впрочем, та же - автоматически удаляется с закрытием сессии.

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

"Быстро, качественно, недорого. Выберите любые два пункта!"
Естественно придется жертвовать памятью ради скорости, либо наоборот.

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

Однако, повторюсь:
1) Лично я бы работал с View.
2) С MS SQL не работал давно, за сим мои мысли о проиводительности можно опустить, как ламерские :)

Потому что view типа "показать данные за 4 недели" несёт смысловую нагрузку только для данного конкретного запроса, который выполняется раз в месяц. Нужен он только для того, чтобы сказать серверу, что я собираюсь сделать 2 раза одинаковую выборку. Если бы это была наполненная смыслом выборка хотя бы для нескольких отчётов, я бы сделал view без вопросов.
каюсь! мне нужно то, (не знаю как оно правильно называется) что самоуничтожится как автоматическая переменная в с++

pva,

Может быть имеет смысл применить функции пользователя ?

Будете передавать в нее две переменных (временной диапазон), получать таблицу.

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

pva, это уже - маленький простой запрос - его можно слегка переформулировать, разбить на части, усложнить. Но MS SQL это не тупой интерпретатор наподобие MySQL - простой запрос он сам выполнит оптимальным образом основываясь на текущей ситуации. Промежуточные таблицы, подпрограммы и т.п. только ухудшат его работу и читаемость.

Занялся народным творчеством дабы улучшить жизнь любимым девушкам в любимой конторе. Родил кучу вопросов. Продолжаем:
1. Есть ли стандартная функция в SQL, которая выбираем минимум или максимум из 2-х значений
2. Можно ли как-то сделать временную функцию (для экономии кода) вида:
на данный момент я сделал в базе функцию
и в запросе стоит 8 раз convert(float, ...) потому что типа неявные преобразования datetime в float не разрешены

а зачем datetime во float переводить? - это немножко хак, без которого вполне можно обойтись.

select предназначен немножко для другого, просто присвоить переменной значение можно через set:
временных функций в T-SQL тоже нету - зачем? Если она нужна - она не должна быть временной; если используется только однажды - красивости можно не наводить. На самом деле, чтобы не "замусоривать" БД - у всех объектов есть владелец и область видимости. Т.е. при правильном проектировании обычный пользователь и не увидит функции и процедуры администратора.

Продолжаем тему про временный view. У меня одна процедурка время от времени блокировала работу всегод отдела. Нужно выбрать последнее по дате значение какого-то параметра из сложного запроса, сделано типа так:
Опытным путём выяснил причину: вот если убрать order by, срабатывает моментом и никого не вешает. В результате переделал так (и всё работает замечательно):
1. можно как-то сделать так, чтобы 2 раза не писать один запрос (типа "сделать временный view")
2. есть ли альтернативные способы выбрать из таблицы элемент с максимальным значением, без такой блокировки других пользователей

Мда.
Задача: Вывести строку в которой d.date максимальна (последнее по дате)
Решение: Вывести ВСЮ таблицу (естественно создается какая-то внутренняя системная буферная переменная), отсортировать (в данном буфере), и взять первое значение.

А если в таблице миллионы строк?

Не индус писал?

Кстати поле d.date - индексированно?
====

Для рекомендаций нужно знать как структуру запроса так и таблиц откуда оно берется.

Временной таблицы не было, стоял большой where, который я переделал в join и переименовал однобуквенные переменные в многобуквенные. Дата проиндексирована (по возрастанию)