Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Странное поведение подчиненного запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Изерлонер
Я топик создал не с целью решения проблемы, а что бы понять чем вызвано подобное поведение запроса.

Вот запросы из тех планов, что вы привели:
+
--fast
Select 
	a.iNumsk, a.iNum, strNumstr, dtDateb, c.strName, bitScan, strNote
FROM 
	Base..tblInvoices_Buh a 
	Inner Join Base..tblContractor_Buh c ON a.iKF = c.iKF 
	Left Join Income..tblIncomeOrder b ON a.iNumsk = b.iNumsk AND a.iNum =b.iNum
WHERE
	c.iKF <> 468 AND 
	iInvoice in (Select iInvoice From BASE.dbo.qryCostFullWithNorm Where IDZAK in ( 1412, 0 ))

--slow
Select 
	a.iNumsk, a.iNum, strNumstr, dtDateb, c.strName
FROM 
	Base..tblInvoices_Buh a 
	Inner Join Base..tblContractor_Buh c ON a.iKF = c.iKF 
WHERE 
	c.iKF <> 468 AND 
	iInvoice in a(Select iInvoice From BASE.dbo.qryCostFullWithNorm Where IDZAK = 1357)

У вас разные запросы и соответственно разные планы. Кроме того, я так понимаю, что под qryCostFullWithNorm скрывается не таблица а представление, в котором затрагивается множество других таблиц. Учитывая все это, неудивительно что время выполнения отличается - это ведь разные запросы.
Если вы привели упрощенные варианты, а в реальности, запросы действительно отличаются только набором ID, то неплохо бы привести действительные планы выполнения, реальных, отличающихся только списком ID, запросов. В приложенных файлах, быстрый запрос - действительный план, медленный - оценочный.

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

Что касается разного числа элементов в списке in - конечно, это может влиять на выбор плана. Ведь чем больше там значений, тем больше вероятность выбора строки, т.е. тем больше будет выбрано строк, и в зависимости от статистики распределения оптимизатор вычисляет сколько предполагается выбрать строк для того или иного значения.
Вот простой пример:
+
use tempdb;
go
create table t1(a int primary key, b int not null, c char(100) not null default(''));
create table t2(a int primary key);
insert into t1(a,b) select number, number%100+1 from master..spt_values where type = 'p' and number between 1 and 1000;
insert into t2(a) select number from master..spt_values where type = 'p' and number between 1 and 1000;
delete top(9) from t1 where b = 1;
update statistics t1 with fullscan;
create index ix_b on t1(b);
go
set statistics xml on
go
select * from t1 join t2 on t1.a = t2.a where b in (1); --estimated row 1
select * from t1 join t2 on t1.a = t2.a where b in (1,2); --estimated rows - 11
go
set statistics xml off
go
drop table t1,t2;

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

Я бы лучше, порекомендовал убрать те места, в которых сильно кривиться оценка, и например, начать с неявных преобразований, попробовать привести схему в порядок. Кроме того, может быть имеет смысл посмотреть, все ли таблицы которые есть во вью, реально нужны в этом запросе.
20 июн 13, 11:18    [14458502]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
SomewhereSomehow
У вас разные запросы и соответственно разные планы.
Если вы привели упрощенные варианты, а в реальности, запросы действительно отличаются только набором ID, то неплохо бы привести действительные планы выполнения, реальных, отличающихся только списком ID, запросов. В приложенных файлах, быстрый запрос - действительный план, медленный - оценочный.


извиняюсь. Я прежде чем отправить на форум «игрался» с запросами, пробовал разные варианты, вполне возможно что недосмотрел и выложил планы разных запросов.
они не должны отличаться, только в условии выборки отличие. завтра выложу нормальные планы (база на рабочем компе).
20 июн 13, 13:17    [14459520]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Действительные планы с корректным запросом. Updatestats выполнен. В таблице tblSumZehWithNorm поставил ключ. Но кластерного индекса так и нет.
План с двумя ИД (быстрый):

К сообщению приложен файл (по 2 ИД.sqlplan - 109Kb) cкачать
21 июн 13, 05:32    [14463111]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
План с одним ИД (медленный), отрабатывался чуть более часа в отличие от первого - тот за долю секунды отработал.

К сообщению приложен файл (по 1 ИД.sqlplan - 108Kb) cкачать
21 июн 13, 05:34    [14463112]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Не очень удобно работать с планами в которых прописан только процент от времени выполнения. Было бы нагляднее что бы там же и время указывалось.
21 июн 13, 05:37    [14463114]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
aleks2
Guest
Изерлонер
В таблице tblSumZehWithNorm поставил ключ. Но кластерного индекса так и нет.

Мсье мазохист.
21 июн 13, 06:55    [14463135]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Мсье прошибает башкой стены, так как другого выбора у него нет.
(если что - моя специальность довольно далека от какой бы то ни было разработки баз данных, но эта область весьма мне интересна. К сожалению реальный мой опыт в этом деле - пол года, то что было ранее вряд ли можно назвать опытом)
21 июн 13, 07:02    [14463139]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3422
Изерлонер,

Начнем с того, что у вас две базы - Base и Income. Вы точно в обеих статистику обновляли? Как-то не верится.

Если сложить содержимое sqlplan-файла в XML-переменную и опросить примерно вот таким запросом:
with xmlnamespaces (default 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
select ro.c.value('./@LogicalOp', 'sysname') as [LogicalOp],
	ob.c.value('./@Database', 'sysname') as [DatabaseName],
	ob.c.value('./@Table', 'sysname') as [ObjectName],
	ro.c.value('./@TableCardinality', 'bigint') as [EstimateRows],
	rti.c.value('./@ActualRows', 'bigint') as [ActualRows]
from @x.nodes('//RelOp[@TableCardinality]') ro(c)
	cross apply ro.c.nodes('./RunTimeInformation[1]/RunTimeCountersPerThread[@ActualRows >= "0"][1]') rti(c)
	outer apply ro.c.nodes('.//Object[1]') ob(c)
order by ObjectName;

то можно увидеть 3 обращения к таблице [tblContractor_Buh] и 2 - к [tblInvoices_Buh], причем статистика везде лажает. Также можно наблюдать забавное количество записей, реально извлеченное в плане с 1 значением из таблицы [tblRequestContent_Buh] - 16740004130. Наводит на мысли о декартовом произведении, хотя может быть и что-то другое.

Давайте уже сюда код этой вашей квери, чую, у нее внутри сидит какая-то жуткая кровавая шизофрения...
21 июн 13, 07:56    [14463204]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Ennor Tiegael
Изерлонер,

Начнем с того, что у вас две базы - Base и Income. Вы точно в обеих статистику обновляли? Как-то не верится.

----

Давайте уже сюда код этой вашей квери, чую, у нее внутри сидит какая-то жуткая кровавая шизофрения...


Вторая база всего с одной таблицей в которой хранятся сканы pdf документов. Занимает весьма много, поэтому отделил ее в отдельную базу... Кажется по базе Income статистику не обновлял сегодня, вчера точно обновлял.

По поводу квери... ну предчувствие Вас не обманывает. Этот запрос базируется на другом запросе, а тот в свою очередь еще на одном. Три уровня запросов. Так получается :( ...Долго все объяснять, я сильно привязан к внешней базе данных сделанной еще в 90е, и довольно кривой. Если бы с нуля сам все делал, то может быть не было бы таких запросов... а так

Запрос номер раз:
SELECT     dbo.qryCostFull.iNUM, dbo.qryCostFull.dtDATENUM, dbo.qryCostFull.strNAME, dbo.qryCostFull.fSHIFR, dbo.qryCostFull.fBORT, 
                      dbo.qryCostFull.fNUMZ, dbo.qryCostFull.IDZAK, dbo.qryCostFull.TypeID, dbo.qryCostFull.Element, dbo.qryCostFull.fCNT, dbo.qryCostFull.fPRICE, 
                      dbo.qryCostFull.fCost, dbo.qryCostFull.strNUMSTR, dbo.qryCostFull.dtDATEB, dbo.qryCostFull.strPost, dbo.qryCostFull.iKOD, dbo.qryCostFull.iElementID, 
                      dbo.qryCostFull.decKODD, dbo.qryCostFull.strNameE, dbo.qryCostFull.iKF, dbo.qryCostFull.iKFSchF, dbo.qryCostFull.ID, dbo.tblSumZehWithNorm.SUMZEH, 
                      dbo.tblSumZehWithNorm.decNormZeh, dbo.tblSumZehWithNorm.decKolZeh, dbo.tblSumIzdWithNorm.SUMIZD, dbo.tblSumIzdWithNorm.decNormIzd, 
                      dbo.tblSumIzdWithNorm.decKolIzd, dbo.qryCostFull.NUMSCHF, dbo.qryCostFull.strSubGroupOfEName, dbo.qryCostFull.decGroupOfEShifr, 
                      dbo.qryCostFull.iInvoice
FROM         dbo.qryCostFull INNER JOIN
                      dbo.tblSumIzdWithNorm ON dbo.qryCostFull.iKOD = dbo.tblSumIzdWithNorm.iKOD AND dbo.qryCostFull.ID = dbo.tblSumIzdWithNorm.ID INNER JOIN
                      dbo.tblSumZehWithNorm ON dbo.qryCostFull.iKOD = dbo.tblSumZehWithNorm.iKOD AND dbo.qryCostFull.ID = dbo.tblSumZehWithNorm.ID AND 
                      dbo.qryCostFull.iKF = dbo.tblSumZehWithNorm.iKF
ORDER BY dbo.qryCostFull.dtDATENUM DESC


Запрос номер два:
SELECT     dbo.qryCosts.iNUM, dbo.qryCosts.dtDATENUM, dbo.tblContractor_Buh.strNAME, dbo.qryCosts.fSHIFR, dbo.qryCosts.fBORT, dbo.qryCosts.fNUMZ, 
                      dbo.qryCosts.IDZAK, dbo.qryCosts.TypeID, dbo.vElement.Element, dbo.qryCosts.fCNT, dbo.qryCosts.fPRICE, dbo.qryCosts.fCNT * dbo.qryCosts.fPRICE AS fCost, 
                      dbo.qryCosts.strNUMSTR, dbo.qryCosts.dtDATEB, tblContractor_Buh_1.strNAME AS strPost, dbo.qryCosts.iKOD, dbo.qryCosts.iElementID, dbo.qryCosts.decKODD, 
                      dbo.qryCosts.strNameE, dbo.qryCosts.iKF, dbo.qryCosts.iKFSchF, dbo.qryCosts.ID, dbo.qryCosts.NUMSCHF, dbo.tblSubGroupOfE.strSubGroupOfEName, 
                      dbo.tblGroupOfE.decGroupOfEShifr, dbo.qryCosts.iInvoice
FROM         dbo.tblGroupOfE INNER JOIN
                      dbo.tblSubGroupOfE ON dbo.tblGroupOfE.iGroupOfEID = dbo.tblSubGroupOfE.iGroupOfEID INNER JOIN
                      dbo.vElement ON dbo.tblSubGroupOfE.iSubGroupOfEID = dbo.vElement.iSubGroupOfEID RIGHT OUTER JOIN
                      dbo.qryCosts INNER JOIN
                      dbo.tblContractor_Buh ON dbo.qryCosts.iKF = dbo.tblContractor_Buh.iKF INNER JOIN
                      dbo.tblContractor_Buh AS tblContractor_Buh_1 ON dbo.qryCosts.iKFSchF = tblContractor_Buh_1.iKF ON dbo.vElement.iElementID = dbo.qryCosts.iElementID


запрос номер три (базовый):

SELECT     dbo.qryRequest_Buh_WithIDZAK.iNUM, dbo.qryRequest_Buh_WithIDZAK.dtDATENUM, dbo.qryRequest_Buh_WithIDZAK.iKF, 
                      dbo.qryRequest_Buh_WithIDZAK.fSHIFR, dbo.qryRequest_Buh_WithIDZAK.fBORT, dbo.qryRequest_Buh_WithIDZAK.fNUMZ, dbo.qryRequest_Buh_WithIDZAK.IDZAK, 
                      dbo.qryRequest_Buh_WithIDZAK.TypeID, dbo.qryRequestContent_With_iElementID.iKOD, dbo.qryRequestContent_With_iElementID.iElementID, 
                      dbo.qryRequestContent_With_iElementID.fCNT, dbo.qryRequestContent_With_iElementID.fPRICE, dbo.tblInvoices_Buh.strNUMSTR, dbo.tblInvoices_Buh.dtDATEB, 
                      dbo.tblInvoices_Buh.iKF AS iKFSchF, dbo.tblGroupOfE_Buh.decKODD, dbo.tblElement_Buh.strNameE, dbo.qryRequest_Buh_WithIDZAK.ID, 
                      dbo.tblInvoices_Buh.iNUM AS NUMSCHF, dbo.tblInvoices_Buh.iInvoice
FROM         dbo.tblInvoiceContent_Buh INNER JOIN
                      dbo.tblInvoices_Buh ON dbo.tblInvoiceContent_Buh.iInvoice = dbo.tblInvoices_Buh.iInvoice INNER JOIN
                      dbo.qryRequestContent_With_iElementID INNER JOIN
                      dbo.qryRequest_Buh_WithIDZAK ON dbo.qryRequestContent_With_iElementID.iRequest = dbo.qryRequest_Buh_WithIDZAK.iRequest ON 
                      dbo.tblInvoiceContent_Buh.iKOD = dbo.qryRequestContent_With_iElementID.iKOD AND 
                      dbo.tblInvoiceContent_Buh.iPART = dbo.qryRequestContent_With_iElementID.iPART INNER JOIN
                      dbo.tblElement_Buh ON dbo.tblInvoiceContent_Buh.iKOD = dbo.tblElement_Buh.iKOD INNER JOIN
                      dbo.tblGroupOfE_Buh ON dbo.tblElement_Buh.iKG = dbo.tblGroupOfE_Buh.iKG


Не думаю что Вам захочется разбираться во всей этой ... шизофрении. ..Хотя это еще более менее нормальный вариант, раньше было еще хуже. Проблема в основном в моих попытках получить из внешней базы хоть как-то упорядоченные данные, и выдать необходимые мне.
21 июн 13, 08:08    [14463223]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
... ну и в том что делалось это все наскоро, лишь бы получить нужный результат в итоге.
21 июн 13, 08:15    [14463233]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3422
Изерлонер,

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

Ну и код лучше выпрямить, как вам уже aleks2 советовал:
declare @t table (Id int primary key);

insert into @t (Id) values (1412);

Select a.iNumsk, a.iNum, strNumstr, dtDateb, c.strName, bitScan, strNote
FROM Base.dbo.tblInvoices_Buh a
	Inner Join Base.dbo.tblContractor_Buh c ON a.iKF = c.iKF
	inner join BASE.dbo.qryCostFullWithNorm q on a.iInvoice = q.iInvoice
	inner join @t t on t.identitycol = q.IDZAK
	Left Join Income.dbo.tblIncomeOrder b ON a.iNumsk = b.iNumsk AND a.iNum =b.iNum
WHERE c.iKF <> 468;
В такой мешанине совершенно ни к чему дополнительно запутывать оптимизатор.
21 июн 13, 09:15    [14463432]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Спасибо.
... понятно что запросы далеки от оптимальности... Тут правда сложности еще с тем что бы понять как получить то что надо. Ну например - как реализовать вьюху в которой помимо числовых данных будут присутствовать и их суммарные значения по какому-либо критерию в каждой строке? (в результате и имеем запрос на запросе).
Зачем такое делается - а для того что бы уже на уровне формы по каждой строке видеть данные, а так же сравнивать их сумму с плановой, и если сумма бьется/перебор/недобор выделять тем или иным цветом (условное форматирование) - для каждой строки.
Для обозначения сравниваются суммы, а для работы необходимы данные. ...Отсюда так же растут ноги таких вот запросов. Ну и, понятно, из за отсутствия опыта.
21 июн 13, 09:50    [14463612]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Изерлонер
помимо числовых данных будут присутствовать и их суммарные значения по какому-либо критерию в каждой строке?

имею ввиду сумму не по записи конечно, а по ... столбцу, по критерию (аналог функции СУММЕСЛИМН из ексель)
21 июн 13, 09:53    [14463628]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Изерлонер,

У вас в плане (что в быстром, что в медленном) по прежнему присутствует конструкция:
--сначала
[Expr1061] = Scalar Operator(CONVERT_IMPLICIT(float(53),[BASE].[dbo].[tblZakaz].[BORT],0)); 
[Expr1062] = Scalar Operator(CONVERT_IMPLICIT(float(53),[BASE].[dbo].[tblZakaz].[SHIFR],0)); 
[Expr1063] = Scalar Operator(CONVERT_IMPLICIT(float(53),[BASE].[dbo].[tblZakaz].[NUMZ],0))

--потом
[Expr1061]=[BASE].[dbo].[tblRequest_Buh].[fBORT] AND 
[Expr1062]=[BASE].[dbo].[tblRequest_Buh].[fSHIFR] AND 
[Expr1063]=[BASE].[dbo].[tblRequest_Buh].[fNUMZ]

Это приводит к очень серьезной ошибке в оценке, на очень низком уровне вложенности операторов плана. По мере того, как оптимизатор продвигается в вычислении кардинальности для верхних операторов плана, ошибка накапливается и искажается все больше. В итоге приводит к печальному расхождению 98 018 vs 16 740 004 130.
Возможно, есть и другие проблемы, но пока вы не поправите эту оценку - ничего хорошего ждать не приходится.
Попробуйте на таблице [dbo].[tblZakaz], создать вычисляемые колонки CONVERT(float(53),[BASE].[dbo].[tblZakaz].[BORT])... и т.д. и соединять таблицы [tblRequest_Buh] и [tblZakaz] по ним. Еще лучше, конечно, привести в порядок типы данных, чтобы они совпадали по этим трем колонкам в обоих таблицах. Но даже вычисляемые колонки должны помочь с оценкой.
21 июн 13, 10:23    [14463784]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
aleks2
Guest
Изерлонер
Не думаю что Вам захочется разбираться во всей этой ... шизофрении. ..Хотя это еще более менее нормальный вариант, раньше было еще хуже. Проблема в основном в моих попытках получить из внешней базы хоть как-то упорядоченные данные, и выдать необходимые мне.


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

Оптимизатор выполняет соединение (JOIN), даже если поля таблиц в нем указанных ваще НЕ используются.

Поэтому пользоваться сложносочиненными VIEW - не надо. Себе дороже.
21 июн 13, 11:11    [14464208]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
aleks2,

возможно вы гений и когда начали изучение баз данных вы сразу знали как именно работает JOIN, как создать WINDOWS, и строение вселенной впридачу.
Вы не знаете ни меня, ни моей ситуации, и я не вижу что позволяет вам судить о моих умственных способностях.
21 июн 13, 11:23    [14464303]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
Изерлонер
Вы не знаете ни меня, ни моей ситуации,


"Долго все объяснять, я сильно привязан к внешней базе данных сделанной еще в 90е, и довольно кривой. Если бы с нуля сам все делал, то может быть не было бы таких запросов"

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

Если вы "Не знаю что такое кластерный индекс", "Я пока на это как баран на новые ворота смотрю :( В акцессе то еще толком не разобрался.", "моя специальность довольно далека от какой бы то ни было разработки баз данных", то считай те такое поведение MSSQL его особенностью или багом.
Для его устранения ваших текущих знаний не хватит.
21 июн 13, 12:36    [14465000]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Сергей Викт.
Member

Откуда: Москва
Сообщений: 888
Изерлонер
aleks2,

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

Я думаю, что чем выяснять межличностные отношения посмотрите снова сюда 14458200.
Это будет полезнее для Вас 100%
21 июн 13, 12:41    [14465048]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
kalimba
Member

Откуда:
Сообщений: 297
SomewhereSomehow,

Сорри за оффтоп, это же SQL Sentry Plan Explorer? А как в нём выводить в диаграмму плана Estimated Rows? У меня только Actual Rows показывает.
21 июн 13, 13:02    [14465239]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Glory
Для его устранения ваших текущих знаний не хватит.

это несколько другое, чем было сказано не находите?

Знаний по данной тематике у меня немного, но стремление их получить есть. Я не прошу решать мои проблемы за меня, здесь много было рекомендаций что делать и на том спасибо. Буду дорабатывать базу в соответствии с ними. А хамить не надо
21 июн 13, 14:30    [14466003]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
Изерлонер
это несколько другое, чем было сказано не находите?

Если вам просто "любопытно", то не надо испытывать терпение других глупыми вопросами.
21 июн 13, 14:34    [14466035]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Изначально было просто любопытно, но это любопытство вывело на такие проблемы о которых я не подозревал. При том сейчас уже вижу как решить часть из них, так что «простое любопытство» очень к месту оказалось. Надеюсь на этом «выяснение отношений» закончено. Не хочу я с вами ссориться. Имейте пожалуйста терпение, и вы спецом наверное тоже не сразу стали, и вопросы разные тоже наверное задавали.
21 июн 13, 14:48    [14466175]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
kalimba,
Вверху, на панели, есть кнопочка Show Estimated Plan.
21 июн 13, 15:27    [14466500]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
aleks2

ЗЫ. Это можно написать прям в запрос Access или процедурой оформить.


не помогло. Проблема в самом qryCostFullWithNorm

Вот такой вот запрос намертво подвешивает комп:

Select DISTINCT iInvoice From BASE.dbo.qryCostFullWithNorm Where IDZAK = 1357


Хотя если в выборке более одного IDZAK
Select DISTINCT iInvoice From BASE.dbo.qryCostFullWithNorm Where IDZAK in (1357, 0)

все работает на ура.


Два дня пытаюсь привести запрос в нормальный (насколько возможно) вид (проблему с неявным преобразованием полей вроде решил, поменял тип данных на int).
Вот пока что получается:

SELECT     dbo.tblZakaz.IDZAK, dbo.ISDvREM.TypeID, dbo.ISDvREM.ID, dbo.tblRequest_Buh.iSHIFR, dbo.tblRequest_Buh.iBORT, dbo.tblRequest_Buh.decNUMZ, 
                      dbo.tblRequest_Buh.iRequest, dbo.tblRequest_Buh.iNUM, dbo.tblRequest_Buh.dtDATENUM, dbo.tblRequest_Buh.iNUMSK, dbo.tblRequest_Buh.iKF, 
                      dbo.tblVsp.iElementID, dbo.tblRequestContent_Buh.iKOD, dbo.tblRequestContent_Buh.fCNT, dbo.tblRequestContent_Buh.fPRICE, dbo.tblInvoices_Buh.iNUM AS iInvNum, 
                      dbo.tblInvoices_Buh.iKF AS iPost, dbo.tblInvoices_Buh.dtDATEB, dbo.tblInvoices_Buh.strNUMSTR, dbo.tblInvoices_Buh.iInvoice, dbo.tblElement_Buh.strNameE, 
                      dbo.tblGroupOfE_Buh.decKODD, dbo.tblContractor_Buh.strNAME AS strZeh, dbo.tblGroupOfE.decGroupOfEShifr, dbo.tblSubGroupOfE.strSubGroupOfEName, 
                      dbo.vElement.Element, tblContractor_Buh_1.strNAME, SUM(dbo.tblRequestContent_Buh.fCNT) Over (PARTITION by dbo.tblZakaz.IDZAK, dbo.tblRequest_Buh.iKF, 
                      dbo.tblVsp.iElementID) as fZehSum, SUM(dbo.tblRequestContent_Buh.fCNT) Over (PARTITION by dbo.tblZakaz.IDZAK, dbo.tblVsp.iElementID) as fIzdSum  
FROM         dbo.tblZakaz INNER JOIN
                      dbo.ISDvREM ON dbo.tblZakaz.IDZAK = dbo.ISDvREM.IDZAK RIGHT OUTER JOIN
                      dbo.tblContractor RIGHT OUTER JOIN
                      dbo.tblVsp LEFT OUTER JOIN
                      dbo.tblGroupOfE_Buh INNER JOIN
                      dbo.tblElement_Buh ON dbo.tblGroupOfE_Buh.iKG = dbo.tblElement_Buh.iKG INNER JOIN
                      dbo.tblContractor_Buh INNER JOIN
                      dbo.tblRequestContent_Buh INNER JOIN
                      dbo.tblRequest_Buh ON dbo.tblRequestContent_Buh.iRequest = dbo.tblRequest_Buh.iRequest INNER JOIN
                      dbo.tblInvoiceContent_Buh ON dbo.tblRequestContent_Buh.iKOD = dbo.tblInvoiceContent_Buh.iKOD AND 
                      dbo.tblRequestContent_Buh.iPART = dbo.tblInvoiceContent_Buh.iPART INNER JOIN
                      dbo.tblInvoices_Buh ON dbo.tblInvoiceContent_Buh.iInvoice = dbo.tblInvoices_Buh.iInvoice ON dbo.tblContractor_Buh.iKF = dbo.tblRequest_Buh.iKF INNER JOIN
                      dbo.tblContractor_Buh AS tblContractor_Buh_1 ON dbo.tblInvoices_Buh.iKF = tblContractor_Buh_1.iKF ON 
                      dbo.tblElement_Buh.iKOD = dbo.tblInvoiceContent_Buh.iKOD ON dbo.tblVsp.iKod = dbo.tblElement_Buh.iKOD LEFT OUTER JOIN
                      dbo.tblSubGroupOfE INNER JOIN
                      dbo.vElement ON dbo.tblSubGroupOfE.iSubGroupOfEID = dbo.vElement.iSubGroupOfEID INNER JOIN
                      dbo.tblGroupOfE ON dbo.tblSubGroupOfE.iGroupOfEID = dbo.tblGroupOfE.iGroupOfEID ON dbo.tblVsp.iElementID = dbo.vElement.iElementID ON 
                      dbo.tblContractor.strContractorShortname = dbo.tblContractor_Buh.strNAME ON dbo.tblZakaz.SHIFR = dbo.tblRequest_Buh.iSHIFR AND 
                      dbo.tblZakaz.BORT = dbo.tblRequest_Buh.iBORT AND dbo.tblZakaz.NUMZ = dbo.tblRequest_Buh.decNUMZ



В связи с этим буду благодарен если ответите на пару общих вопросов (в частности не надо углубляться, мне бы общие принципы понять, дальше сам дойду):

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

2. В приведенном запросе отсутствует важная часть. Сумма по данным иерархического (рекурсивного) запроса. Т.е. имеется еще рекурсивный запрос (если надо, текст запроса приведу, но для общего вопроса мне кажется это не является необходимым), к которому надо применить агрегатные функции и подставить результаты в поля приведенного запроса. При попытке "всунуть" сюда еще этот рекурсивный запрос да еще с группировкой, да с соединением по нескольким (трем) полям производительность резко падает. Пока думаю как вариант имеет смысл создать отдельную таблицу в которую засылать данные рекурсивного запроса (благо перерасчитывать каждый раз это все нет необходимости), и использовать в запросах уже только эту таблицу. А какие вообще могут быть здесь варианты.

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

P.S.: я слышал что соединения типа Left Join, Right Join в подобных запросах не желательны, но уйти от них пока не вижу возможности.
23 июн 13, 20:09    [14470891]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение подчиненного запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Для наглядности еще картинку приведу. ...Понимаю что все это выглядит не очень хорошо, но хотя бы от трех - пяти уровней запросов, один над другим вроде ухожу... исключая запрос с рекурсией, которого я пока здесь не приводил.
Буду благодарен за общие советы.

К сообщению приложен файл. Размер - 78Kb
23 июн 13, 20:16    [14470908]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить