[pva]

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

Код:

accDebet join accCliPay on (accCliPay.accPayId=accDebet.accPayId and accCliPay.payCod=1)

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

[Busla]

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

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

Код:

select *
  from
    (select * from accDebet join accCliPay on (accCliPay.accPayId=accDebet.accPayId and accCliPay.payCod=1)) as u1,
    (select * from accDebet join accCliPay on (accCliPay.accPayId=accDebet.accPayId and accCliPay.payCod=1)) as u2
  where
    u1.dateIn>'2008-08-15' and u2.dateIn>'2008-08-15' -- 4 недели назад - лучше вынести в переменную
    and u1.groupId=u2.groupId2 and u1.recId<>u2.recId
    and u1.dateIn>=u2.dateIn and u1.dateIn<=u2.dateOut

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

[pva]

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

[kim-aa]

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

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

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

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

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

[pva]

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

Поэтому и подумываю как бы тут view применить

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

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

[kim-aa]

Оставлять view навека в базе не хочется »

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

Всё-таки временную таблицу (declare @t1 table...) сделать? »

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

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

[Busla]

Временная таблица, ( т. е. та которая существует только во время сессии - я правильно вспомнил терминологию MS SQL? »

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

Тоже не плохой выход, особенно с точки зрения, работы с высоконагруженными базами. »

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

[kim-aa]

но временную таблицу ещё надо где-то хранить и строить к ней свои индексы. »

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

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

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

[pva]

Цитата pva: Оставлять view навека в базе не хочется » А почему собственно? Они для этого и предназначены. »

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

на самом деле pva путает понятия временная локальная таблица и таблица-переменная »

каюсь! мне нужно то, (не знаю как оно правильно называется) что самоуничтожится как автоматическая переменная в с++

[kim-aa]

pva,

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

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