![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Виртуальные таблицы в TSQL
MsGuns © (2009-01-20 12:40:00)Вопрос возник из-за отсутствия в TSQL конструкции Select from <StoredProc>
Есть запрос на выборку Select... на который нужно наложить дополнительное условие (Where, Join, In..) на соответствие некоторому набору значений поля (полей), определяемому хранимкой. Однако вставить в запрос на выборку непосредственно ХП нельзя. Если ХП сохранит результат во временной таблице #Table, то она "не видна" извне. Создавать на клиенте (в большинстве случаев запрос формируется на клиенте) временную таблицу и передавать ее имя в ХП не желательно по ряду причин.
Как выйти из тупика ?
MsGuns (2009-01-22 11:20:00) [1]>Медвежонок Пятачок © (21.01.09 16:12) [22]
>ганс, юзай мою методу, будет щастье.
Дадад, сразу как только с делфей пересяду на жабу, а мсскл поменяю на постгрес :)
MsGuns (2009-01-22 11:18:00) [2]>Сделай наоборот: функционал - в функции. В процедуре, "используемой скризь и рядом" >останется SELECT * FROM <ProcName>
Мысль, конечно, хорошая, но ты знаешь, мне она тоже пришла в голову. Причем в самом начале.
Но эта "навороченная" ХП в свою очередь использует еще несколько других ХП. Тоже не маленьких..
В общем ситуация когда дачный сортир пытаются перестроить в особняк :)
ЮЮ (2009-01-22 03:24:00) [3]
> Я же вроде подробно написал о том, что не хочется ДУБЛИРОВАТЬ
> процедуру функцией.
> Переделать ХП в ф-цию нельзя потому что она используется
> в бизнес логике и на клиентах скризь и рядом :)
> Навороченность не от того, что говнопрограммисты писали,
> а оттого, что сам по себе расчет достаточно сложный - стандарты
> такие, обусловленные спецификой отрасли. Да и вылизана эта
> ХП так, что оптимизировать особо уже некуда. Она, кстати
> весьма реактивная :)
> > В теле функции нельзя взывать процедуры
Сделай наоборот: функционал - в функции. В процедуре, "используемой скризь и рядом" останется SELECT * FROM <ProcName>
А на клиентах получишь желаемое:
SELECT ...
FROM
<ProcName> p
JOIN ... ON p.xxx = ...
или
SELECT ...
FROM
<ProcName> p
WHERE p.xxc IN (...)
tesseract (2009-01-22 00:45:00) [4]
> вот что бывает когда не любишь xml
Да кто его любит? Максимум его преимуществ перед ini - это хранение иерархических настроек.
ЗЫ: CSV рулит :-)
sniknik (2009-01-22 00:41:00) [5]база pubs, там какаято процедура reptq1, при подключении к этой базе ->
SELECT a.*
FROM OPENROWSET('SQLOLEDB','127.0.0.1';'sa';'123456', 'exec pubs.dbo.reptq1') AS a
sniknik (2009-01-22 00:32:00) [6]> Значит [10] ;)
тогда можешь пожертвовав производительностью получить рекордсет из процедуры через OPENROWSET подключая ее к своей же базе как к внешней.
это можно вставлять прям в запрос с джойном.
MsGuns (2009-01-21 23:53:00) [7]>sniknik © (21.01.09 21:29) [28]
>не совсем понял написанное в [9] (читай совсем не понял)
Значит [10] ;)
Ладно, всем спасибо
sniknik (2009-01-21 21:29:00) [8]> см. [9]
не совсем понял написанное в [9] (читай совсем не понял), но увидел страшное слово "дублировать", а кто предлагал дублировать? там выполнение той самой процедуры, которая и так по твоим словам уже возвращает рекордсет... т.е. добавляется 3 строчки к sql пакету - создание временной таблицы, получение рекордсета из процедуры в нее, и удаление ее после, а до удаление вставляешь то что ты там хочешь с джойнами и вообще с чем хочешь.
и утяжелением добавление в ADODataSet 3х строк (или даже 30ти) я бы не назвал, так, мелкая добавка.
Медвежонок Пятачок (2009-01-21 21:11:00) [9]вот что бывает когда не любишь xml
MsGuns (2009-01-21 21:06:00) [10]Спасибо. Похоже нет щастья на белом свете :(
Будем утяжелять клиента
Медвежонок Пятачок (2009-01-21 16:34:00) [11]ini-файлы рулят
не. временные файлы интернета - вот кто рулит.
Медвежонок Пятачок (2009-01-21 16:23:00) [12]он позволяет обойтись без костылей
Ega23 (2009-01-21 16:19:00) [13]
> ганс, юзай мою методу, будет щастье.
XML - гуано, ini-файлы рулят
Медвежонок Пятачок (2009-01-21 16:12:00) [14]ганс, юзай мою методу, будет щастье.
Ega23 (2009-01-21 16:09:00) [15]
> Типа при помощи кувалды и какой-то матери :(
if exists (select * from sysobjects where id = object_id(N'[S_TestProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [S_TestProc]
GO
CREATE PROCEDURE S_TestProc
@Condition varchar(8000) = '1=1'
As
Set NoCount ON;
Create Table #temp (
uid int identity (1,1),
aName varchar(64)
);
insert into #temp (aName) values ('A1');
insert into #temp (aName) values ('A2');
insert into #temp (aName) values ('A3');
insert into #temp (aName) values ('A4');
insert into #temp (aName) values ('A5');
insert into #temp (aName) values ('A6');
insert into #temp (aName) values ('A7');
insert into #temp (aName) values ('A8');
insert into #temp (aName) values ('A9');
insert into #temp (aName) values ('A10');
insert into #temp (aName) values ('A11');
exec ('Select * from #temp where ' + @Condition);
return(0);
GO
-- S_TestProc @Condition='uid>5';
MsGuns (2009-01-21 15:24:00) [16]>Ega23 © (21.01.09 12:23) [16]
>Через Exec. Динамический запрос, вобщем.
Типа при помощи кувалды и какой-то матери :(
>b z (21.01.09 14:16) [19]
>Так я и говорю, что может отказаться от ее использования в пользу позрачности, скорости и т.д.
>Ну в общем трудно судить не видя реалии, может и она не такая навороченная, может ее >переделать
Я же вроде подробно написал о том, что не хочется ДУБЛИРОВАТЬ процедуру функцией.
Переделать ХП в ф-цию нельзя потому что она используется в бизнес логике и на клиентах скризь и рядом :)
Навороченность не от того, что говнопрограммисты писали, а оттого, что сам по себе расчет достаточно сложный - стандарты такие, обусловленные спецификой отрасли. Да и вылизана эта ХП так, что оптимизировать особо уже некуда. Она, кстати весьма реактивная :)
>а может уже что-то из предложенного хватит (например sniknik © [8], оно отвергнуто? >почему?) ... да мало ли.
см. [9]
b z (2009-01-21 14:16:00) [17]
> Медвежонок Пятачок © (21.01.09 14:03) [18]
Так я и говорю, что может отказаться от ее использования в пользу позрачности, скорости и т.д.
Ну в общем трудно судить не видя реалии, может и она не такая навороченная, может ее переделать, а может уже что-то из предложенного хватит (например sniknik © [8], оно отвергнуто? почему?) ... да мало ли.
Медвежонок Пятачок (2009-01-21 14:03:00) [18]так фикус-то у него в том, что динамические условия очень сложные и они уже реализованы в супер процедуре.
b z (2009-01-21 13:41:00) [19]
> В теле функции нельзя взывать процедуры
А у вас там еще есть вложенные процедуры?
> Для чего и требуется "прикрутить" джоин к деталям и сборкам,
> относящимся к УКАЗАННОМУ изделию, а список этих самых деталей
> и сборок выдает та самая ХП.
хм, а зачем вам тут - "та самая ХП"? просто вставить необходимые условия "по месту" никак, т.е. все в одном?
кажется, что вам надо зайти с другой стороны :) т.е. пересмотреть реализацию алгоритма, может быть что-то гдет-то сделать вложенными запросами или ...
недавно вот тоже делали автоматические расчеты на сервере, вышло около десятка процедур и несколько функций, тоже была засада в реализации элементов/алгоритмов комбинаторики ... решили с помощью clr (2005 сервер) + #temp таблицы, чуть-чуть подумали и все
а у вас пока выглядит как "дополняет условием Where исходя из текущих локальных требований пользователей", но делаете "странными" методами.
если таких параметров много и лень расписывать их всех, то дин. формирование запроса должно хватить, иначе и его наверное не надо
естественно, могу ошибаться
Ega23 (2009-01-21 12:23:00) [20]
> Не понял, каким боком в эту новую ХП я смогу встромить клиентский
> запрос с его (клиента) же списком where
Через Exec. Динамический запрос, вобщем.