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

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

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

Изначально работал в эксель. С учетом количества обрабатываемых данных это вообще мрак. Переход на базы данных существенно улучшил ситуацию, и открылись новые возможности.
План минимум - создать рабочее место нормировщика, удобный и быстрый инструмент для анализа и обработки данных. Реализуется.
Следующая цель - создать многопользовательскую базу данных для работы в ней смежных отделов, каждому свой участок, пока включая ближайшие отделы. Продумывается. Изучается.
План максимум электронный документооборот всего предприятия. Да, вполне вероятно до этого не дойдет. Но это ориентир, маяк.
2 дек 13, 05:09    [15222593]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Что такого могут БД что помогают увидеть/сделать?
Своей простотой? Досягаемостью? Ближе к реалям?

Своей эффективностью. С использованием грамотной базы данных эффективность работы возрастает ... даже не в разы, на порядки. Учитывая огромную долю ручного труда на нашем предприятии. Ну в лучшем случае люди эксель знают... да и то "знают" слишком сильно сказано. Все разрозненно, все себе на уме. Даже тупо телефонного справочника нет общего, как надо по предприятиям звонить начинается беготня с выспрашиванием друг у друга номеров телефонов... Про большее не говорю.
2 дек 13, 05:18    [15222600]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Насчет эффективности я это на своей собственной шкуре прочувствовал. Когда только начинал работать на данном рабочем месте довольно не редко было - прихожу в девять утра на работу и без перерывов пашу до пяти утра следующего дня, потом домой час - два на сон и в девять утра снова на рабочем месте. Я не придумываю - так было несколько раз. Более "мелких" вечеровок несчесть. С тех пор требования и количество данных еще возросло - но я уже сдерживаю это и могу работать нормальный восьмичасовой рабочий день (исключая отдельные авралы). Правда частенько теперь по вечерам дома с базой данных сижу... когда семья позволяет.
2 дек 13, 05:34    [15222603]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
По крайнему Вашему варианту запроса... подход в общем понятен. На выходе данные не верные. В чем проблема постараюсь разобраться денька за два (ну или как получится). ...Например рекурсивный запрос ... он должен выдавать по сути те же самые данные, за минусом лишних полей. Остаются только iElementID и iElementID_Parent ... ничего подобного. На выходе получаются дублирующиеся строки и... думаю это не единственная проблема. Не проблема Вашего решения, проблема моих исходных данных. Что в таблицах забито...
Вторая проблема - отсутствует iIndex_Parent по которому определяются варианты комплектации и по какому правилу собственно вычислять.
2 дек 13, 15:34    [15226059]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Дайте время мне самому попытаться разобраться.
2 дек 13, 15:39    [15226117]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4

;WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	FROM	dbo.tblNodeElement	P
-- Если будет неправильный план (тормозить) - разкоментить
--	JOIN	dbo.tblNodeElement	E ON P.iElementID = E.iElementID_Parent
--	WHERE	E.iElementID = @iElementID
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	FROM	[Parents]		E
	JOIN	dbo.tblNodeElement	P ON P.iElementID = E.iElementID_Parent
)
	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID
			THEN ZN.decZehNorm * X.decNodeCnt
			ELSE 0 END)			AS ZehNormSum
	,	Sum(ZN.decZehNorm * X.decNodeCnt)	AS IzdNormSum
	FROM	dbo.tblNodeElement	NE
	JOIN	[Parents]		NP ON NP.iElementID	= NE.iElementID_Parent
	JOIN	dbo.tblZehNorm		ZN ON NE.iNodeElementID	= ZN.iNodeElementID
--LEFT	JOIN	dbo.tblElement		EP ON EP.iElementID	= NE.iElementID_Parent
--	JOIN	dbo.tblElement		EE ON EL.iElementID	= NE.iElementID
CROSS APPLY (SELECT	
	1	--	IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)	-- ?
			)	X (decNodeCnt)
	WHERE	NE.iElementID = @iElementID
	AND	NP.iElementID_Parent = @iElementID_Root

Значится так, предварительная попытка разобраться... мне кажется или я вообще уже ничего не понимаю, или Вы не правильно меня поняли. Не воспримите пожалуйста как упрек. Наверное мне нужно все таки начинать с начала. Выдавать скрипты участвующих в запросах таблиц, объяснять все ограничения, и объяснять что конкретно нужно. ... Иначе мы так далеко уйдем и ничего по сути не решится. Тем более учитывая что весь этот запрос по сути промежуточный этап... и вообще бы лучше от него избавится.
Я сначала как увидел ваш рекурсивный запрос, подумал - ух как классно, вы все лишнее из него убрали, оставили только одну таблицу, да и в ней лишь два поля, а уж потом к ней джойните нужные данные. Быстро летать будет наверное... Идея то классная, но как говорится со всем лишним выплеснули и младенца, все то что необходимо для корректного расчета. И это не только мудреные индексы взаимозаменяемости, но к примеру и вот это:
SELECT	1	--	IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)	-- ?

...я вижу вопрос, понимаю что для вас этот момент не понятен что это вообще и зачем.
В предметной области вот это вот
NL.decNodeElementCnt * NL.decNodeElementCnt_Parent
- количество узлов (сборочных единиц конкретной номенклатуры) устанавливаемых на изделии (при этом в данном конкретном случае NL.decNodeElementCnt это количество узлов, т.е. родителей, а NL.decNodeElementCnt_Parent это родители родителей... если я к двум часам ночи еще не загнался....
Вот это вот:
ZN.decZehNorm
норма расхода запасных частей/материалов устанавливаемая на данный узел.
К примеру имеем узел А с подшипником П, норма расхода этих подшипников на узел 0,1 (меняется один подшипник на десять узлов). Узел А стоит на изделии И, и узлов этих в разных местах изделия допустим 3. Кроме того, подшипник П может стоять не только в узле А, но и в других узлах на разных уровнях, для простоты возьмем что 5 шт подшипников П стоит непосредственно на самом изделии (при этом и норма расхода ZN.decZehNorm здесь у них своя (что логично, износ подшипников в разных узлах, в разных местах может идти по разному) Примем норму = 0,5 (на все пять подшипников, "родитель" у них один, само изделие).
В итоге получаем норму расхода подшипников П на ремонт изделия И
decZehNorm1*decNodeElementCnt1 * NL.decNodeElementCnt_Parent1 +decZehNorm2*decNodeElementCnt2 * NL.decNodeElementCnt_Parent2 = 0,1*3*1 + 0,5*1*1= 0,8. Что значит на десять ремонтируемых изделий И расходуется 8 шт подшипников П. Если сюда еще добавить весь гемор с взаимозаменяемостью (iIndex) можете себе представить что все расчитываться будет совсем не так просто.
С рекурсивным запросом я вообще смысла не понял. Вы вытаскиваете из таблицы tblNodeElement и детали и узлы (а так как один и тот же узел может стоять в разных изделиях, в разных узлах, на разных уровнях идет дублирование)... что и для чего я так и не вкурил. Ну ведь пары iElementID - iElementID_Parent итак в таблице tblNodeElement хранятся, там рекурсии не надо что бы их достать. Рекурсия нужна что бы само изделие определить iElementID_Root, ну и на каком уровне сборки находится та или иная деталь, тот или иной узел. Дерево построить, что и куда входит... короче я так пока и не понял зачем все это. Смысла не отрицаю, просто пока не понял.

Что бы из пустого в порожнее не переливать предлагаю выложить скрипты участвующих в запросе таблиц. Объяснить их связи, и что должно получится на выходе.
Скрипты сделать не проблема. Вот как бы наполнить их данными может подскажете? Ну что бы вручную не забивать все данные в скрипт, а взять выборку какую из реальных таблиц. Это возможно сделать по простому средствами MS SQL?

Так же помню про Ваш совет с дополнительными полями в таблицах куда будут вносится вычисляемые данные, которые будут перевычисляться при каждом изменении касающихся данных. Это наверное наиболее простой и быстрый выход.
2 дек 13, 19:43    [15227945]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Изерлонер
И привести их в порядок, сделать стройную систему которая и "домохозяйке" была бы понятна весьма не просто ...
1. Проблема не в бардаке в системе, а у вас и то что вы вываливаете на нас.
2. Просто. Откройте для себя синонимы и представления.
Переименовываете название таблиц и колонок, расширяете где-что и пишите представление со старым названием таблицы и колонок. Всё работает как работало, зато теперь вы можете писать и переписывать с нормальными названиями, сохранив нам глаза.

Я говорю про мелочный бардак, который вы всё откладываете вычистить. Переименуйте, уберите мелочи (NOT NULL). Я всегда начинаю с них - ибо не нужно перелопачивать логику приложения/системы. А далее можно переписывать куски.
Вы так не накапливаете бардак, переписывание с нуля дороже стоит - ещё надо и переносить. Этот подход не работает (кроме как для попила на верхнем уровне).
Изерлонер
сделать скрипты самой базы данных и выложить сюда, так и сделаю
Я не буду вычищать мелкие баги. Если их много я просто уйду. Это вы сами можете исправить. Они элементарны.
Изерлонер
Многие подузлы и детали могут быть взаимозаменяемыми. Задал вопрос здесь на форуме мне посоветовали довольно интересное, хотя может и не бесспорное, решение.
Так накуя назвали вы его Index? И почему кратное ста? Зачем?
Код детали это одно. Код заменяемости это другое. Нельзя смешивать понятия. Нельзя соединять не соединяемое.
Экономили на колонке? Всё равно обе колонки нужны по отдельности.
Выправьте это сразу же. И больше не приводите эти Index и /100. Ок?!
Изерлонер
В таблицу элементов (детали, агрегаты, изделия, материалы - тупо справочник всех возможных элементов)
Зачем вы всё в кучу свалили?! Это самое плохое что делается. Это программисты так любят обобщать иногда. На деле должно быть строго по Предметной Области (ПО).
Изерлонер
дальнейшая проработка уже моя, за эту идею ухватился.
Вот видите, дело не в ПО, а в бардачности. В том что вы путаете людей, а не ПО запутанное. Я понимаю наоборот, когда одно понятие раскалывается на несколько таблиц - что правильно.
Изерлонер
Ввел для себя понятие базовой детали и базовой комплектации - это какая-то конкретная комплектация и деталь принимаемая для агрегата по умолчанию. Для нее и расчитываются все нормы и количества деталей.
Колонки в базе должны так и называться. По буржуйски, по русски или по китайски не важно, главное не так непонятно.
Изерлонер
Но так как в нормативах желательно указывать и взаимозаменяемые узлы и элементы ...
Это всё элементарно и подразумевается из названий колонок. Поэтому обе колонки и пишутся ... короче. Не вижу проблем в предметной области. Проблема в вас.
Изерлонер
проще наверное будет скриптов наделать с базы и выкладывать, тогда может быть и понятнее будет.
Уже не будет. Уже итак понятно что неправильно. Вот сначала нормально всё исправьте, чтоб повторно нам в этом говне не разбираться.
Изерлонер
Я тут довольно жестко привязан к старой базе складского учета сделанной в 90-х еще под ДОС. Используется она на предприятии весьма активно.
Ни на что это не влияет. В том -то и приемущество SQL - пока вы может менять БД - вы можете вычищать баги оставив систему работоспособной.
Более того в итоге вы получите и нормальную систему и связку со старой. Переписать и написать конвертор - это неподъёмная задача, за короткий срок темболее.
А так вы малыми заменами структуры, не спеша приведёте всё к норме и простоте. Создавая представления для старого вида.
Изерлонер
....Вообще база ужасная я полтора года башку ломал пока разобрался что и как там работает.
Вы зря потратили время, ибо воз и ныне там. Ваша башка ничего не стоит, обстоятельства - смена работы и хамба всем этим "знаниям".
Вычищать надо. Увидел и тут же исправил.
Полтора года большой строк. Даже для сильной занятости.
Изерлонер
Подход взял из нее. И мне кажется это довольно удобно. Зачем мне отдельные таблицы поставщиков, клиентов, и подразделений если все это имеет фактически одну структуру, да и в той базе это уже сделано так и я не могу на это повлиять? С тем что бы доставать нужные данные проблем не возникало.
FacePalm.jpg
Вы натянули силой всё на одно. Нет там ничего общего. Вообще.
Общее, точнее одно и тоже (к примеру разные типы пользователей) - это кидается в одну таблу, ибо одна сущность. Но у этой каждой сущности будет своя расширительная таблица с колонками, со смыслом только для неё.
Далее пишется на каждую сущность представление, которые в себе соединяет все эти связанные колонки (далее я могу вас научить писать представления).

А если у вас есть хотя бы одна колонки которая имеет смысл только для части строк - это не нормализованная таблица, это бардак и это путает всех остальных - нормальных людей.
Надо понять главное - логическая сущности это не таблицы, это просто абстрактные вещи. А таблицы подстраиваются под задачи, под эффективность. Поэтому в большей частью обращение нужно писать к представленям - вот ваш повседневный инструмент.
(Как есть интерфейсы/классы и базовые классы, типы и другие сущности).
Изерлонер
Или зачем мне разделять например таблицу элементов отдельно на таблицу материалов, отдельно на запчасти, если достаточно просто признак ввести, группы и подгруппы для определения что это такое.
Хватит перфекционизма.
Есть 100500 причин почему нельзя (все не озвучить).
1. Статистика - грохается производительность на корню.
2. Не читабельно.
3. Неповоротливость разработки (расширение будет уже не нормализованно).
4. Неявные вещи скуль не видит - "там всегда NULL, а тут не бывает наследников, а там другое". Он не может в отсутствии чётко и конкретно описанных вещей угадывать правильные планы.
Самое главное в декларативном программировании - скорость разработки. Так вы её убили полностью.
Т.е. и не формализовано, непонятно, не эффективно и медленно в разработке. Чистейшее зло.

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

Вот, повторяю. Дело не в предметной области, не в вашем незнании SQL, а только в вас и вашем подходе.
Бегут от вас именно поэтому и только.
Будет правильный подход, будете знать как на SQL это делать, автоматически.
Изерлонер
Mnior
Убрали бы вот эти ляпы ...
Сделаю.
Надеюсь. Там работы непочатый край. А далее можно учить формализмам и лишь потом оптимизации.
Изерлонер
Я хочу что бы у меня все было красиво, доступно и понятно.
Пока это не видно.
Изерлонер
Но когда горит - надо пожар тушить, а не о красоте думать.
Хотите скажу правду:
"Вам быстро за месяц или медленно за неделю".
Часто люди спешат по первому варианту.
Но как только хотя бы раз они сделали по второму, они перестают говорить как вы.
Почему-то уверен что вы не делали не торопясь и вдумчиво. И следовательно вы не можете говорить что "при пожаре не до красоты".

И "красота" тут совершенно не причём. Это у вас как раз навалом - перфекционно соединяете таблицы, думаете не о том.
Но я вас не смогу убедить - вы всё равно будете думать в своём ракурсе. Вы оперируете другими вещами, другое ставите во главу угла.
Изерлонер
А вот когда пожар потушу, можно будет спокойно и порядок навести (если дадут).
Наивняк. Прокрастинация вас замучает как пить дать. И не дадут никогда. Делается то что в первую очередь и делается, остальное только если повезёт.

Единственное, что правильно, когда надо остановится в создании/изменении, делать малыми порциями, а не "сделаю/заменю всё сразу". Но и не оставлять один-два недоделанных элемента. Или браться за другое, недоделав первое.
Изерлонер
Не издеваюсь, собственно оно так и есть расчет для каждой строки (поправлюсь только - для каждой строки с означенными критериями - конкретный iElementID, iElementID_Root, iContractorID для других значений этих параметров и на выходе другие значения будут)
Плять. Мы с вами о чём говорим о DISTINCT или об одной строке?
Обычная логика:
Если у вас по всем строкам одинаковый результат - Зачем подсчитывать по каждой строке? (и за тем DISTINCT)
Если одна строка - независимо от параметров, значит её можно выкинуть вообще. Связав (CROSS JOIN) два запроса-агрегата (которые возвращают по одной строке (одной колонке)).
Это же элементарнее чем 2+2! Что вам не понятно в этом запросе?
А далее это уже я свернул два запроса в один. Хотя это тоже элементарно.
Изерлонер
Я просто не знаю как можно сделать по другому и можно ли. Может быть Вы посоветуете?
Что-то не верится что вы не гуманитарий. Гуманитарии только боятся ("а можно ли") экспериментировать. Настоящий технарь всё делает сам, он изучает всё сам. Не у учителя, не по книгам, зубрит. У него всё это только задаёт тему интересов, для его подхода.
Он не задаётся "а знаю ли", он сразу же не раздумывая тут же ставит эксперимент и через секунду-минуту имеет результат. Результат осмысления предмета. Настоящий технарь, это не тот что тушит чужой пожар, не зная как, настоящий технарь делает своё и у себя на уме, чужой пожар это поле для применения навыков и постановки своих экспериментов.
Ответ есть всегда - в любой области, первый раз или нет. Интроверт (технарь) не взвалит на себя непосильную задачу.
Взваливать на себя ответственность которую заранее известно что не подымешь - это безответственно.
Изерлонер
Вы ошиблись в нескольких местах Я технарь. Инженер по машиностроению.
Причём тут образование/специальность к социотипу?!
Среди прогеров много гуманитариев. Я бы даже сказал не меньше чем в жизни, а их большинство (ибо реальность требовала свои стратегии).
Изерлонер
Насчет того что я экстраверт ...
Я путаю порой функции экстраверсии и рациональности.
А "не видят и не слышат" к экстраверсии не относится, так явно. Это функция направления восприятия на внешний мир или на внутренний (по Соционике).
Изерлонер
а вообще полностью дезориентирован что от тебя вообще требуется. Зато периодически получал по башке от руководства, и за дело, а гораздо чаще и без дела, нет уж хватит.
Жызнь. Хныкать того не стоит.
Изерлонер
вот только не нужен руководству такой специалист.
Это нормально. Мы пока в каменном веке живём.
Гуманитариев большинство. Они держат быт и социальность. Человеческие сущности как стремление к осмыслению (формализму) для выживания не нужны.
Да и эффективность никому не нужна. Можно зарабатывать на распилах - меньше гемора.
Изерлонер
а я за совет огреб капитально... на всю жизнь запомню.
То ли отношение запомните?
Просто надо находить нормальных людей, а от гнилой головы держаться подальше. Оно того не стоит. И делать всё тише и аккуратнее.
Вот на западе проще - можно хоть не работать и скинуть всё на другого, договорившись. Простая система договорённых отношений. Это у нас развитый феодализм. (там конечно тоже, но просто лучше в этом плане: феодал моего феодала - не мой феодал )
Изерлонер
альтернатив особо нет.
Вы главное о себе не забывайте. Работа работой, а про обучение не забывайте - это отличное капиталовложение. Главное чтоб у начальства не было альтернатив, особенно у такого.
Не думаю что нет у вас альтернатив - можетв вы не умеете их искать?
Изерлонер
Следующая цель ... План максимум электронный документооборот всего предприятия.
Амбиции.
Не забывайте что система живёт и меняется, а не - сделал и работает вечно. Так и сдыхают системы - от неповоротливости.
2 дек 13, 22:51    [15228690]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Изерлонер
SELECT	1	--	IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)	-- ?

...я вижу вопрос, понимаю что для вас этот момент не понятен что это вообще и зачем.
Неа. Не угадали.
Там всё рабочее, откоментировать не дрова возить, щёлк и готово. Это намёк что вы на столько не уделяете время нам показать что либо, что на тех единичных данных что вы выложили - это срока не имеет смысла (там везде NULL).
Изерлонер
В предметной области вот это вот
NL.decNodeElementCnt * NL.decNodeElementCnt_Parent
- количество узлов (сборочных единиц конкретной номенклатуры) устанавливаемых на изделии (при этом в данном конкретном случае NL.decNodeElementCnt это количество узлов, т.е. родителей, а NL.decNodeElementCnt_Parent это родители родителей... если я к двум часам ночи еще не загнался....
Что-то я не вижу там агрегаток. Или это количество деталей в изделии. Самое непонятное, что смотрится только на родителя, а от CTE обычно ожидается цикличность (родитель-родитель-...), поэтому я сразу вынес, чтобы показать и не запутать остальных (как обычно девиз - не смешивать понятия).
Изерлонер
ZN.decZehNorm - норма расхода запасных частей/материалов устанавливаемая на данный узел.
Из названия это и так понятно. [СonsumptionRate] - на буржуйском
Изерлонер
К примеру имеем узел А с подшипником П, норма расхода этих подшипников на узел 0,1 (меняется один подшипник на десять узлов). ...
Вы что считаете нас тупыми? Технарь воды не любит. А тут у вас вырежи 70% слов смысла не убавится.
Изерлонер
Если сюда еще добавить весь гемор с взаимозаменяемостью (iIndex) можете себе представить что все расчитываться будет совсем не так просто.
Вы издеваетесь пока тут вообще детский лепет.
Вы обходите стороной взаимозаменяемость. Какая разница заменяется ли деталь или нет, её расход же считается одинаковым? Т.е. расход идёт на супер-изделие (абстракция объединяющая все изделия которые можно впихнуть в данный узел, оно ща у вас назвается [Index/100]), т.е. одинаков для взаимозаменяемых, т.е. привязан к узлу, т.е. "индекс" по барабану?
Если нет, тогда как рассчитывать норму расхода? (типа заменяемые детали A1 и A2 имет в узле нормы N1 и N2. И что? А если я буду ставить только A2?)
Изерлонер
С рекурсивным запросом я вообще смысла не понял. Вы вытаскиваете из таблицы tblNodeElement и детали и узлы (а так как один и тот же узел может стоять в разных изделиях, в разных узлах, на разных уровнях идет дублирование)...
Вы тормозите (или у вас система ахтунг). И к тому же, откуда дубли - у листа один родитель, у которого тоже один родитель. Нет разницы как обходите дерево. Если собирать дерево сверху то тоже "дублируется" - выходите из корня не несколько узлов с той же деталью.
Или вы не инженер или вы запутались.
Изерлонер
Ну ведь пары iElementID - iElementID_Parent итак в таблице tblNodeElement хранятся, там рекурсии не надо что бы их достать.
По закомеченным JOIN это и видно. Рекурсия не используется.
Изерлонер
Рекурсия нужна что бы само изделие определить iElementID_Root
А вы что этого не видите в моём рекурсивном запросе?
Запустите [Parents] отдельно - это все родители для всех узлов. Две связки связывают изделие с деталью (рекурсия связывает всю линию родителей).
	JOIN	[Parents]		NP ON NP.iElementID	= NE.iElementID_Parent
	WHERE	NP.iElementID_Parent = @iElementID_Root

Изерлонер
ну и на каком уровне сборки находится та или иная деталь, тот или иной узел.
Где у вас есть это понятие "уровень"??!! (5й уровень, 6й) А нету! Ибо вам это не нужно. Так зачем спрашиваете?
Изерлонер
Дерево построить, что и куда входит... короче я так пока и не понял зачем все это. Смысла не отрицаю, просто пока не понял.
Плять. Я начинаю вспоминать того программиста. (хоть имена в вас разные)
Зачем строить дерево? Для красоты? Дерево построить нельзя - скуль не графическая система. Можно воспользоваться древовидной структурой. Оба запроса (первоначальный ваш и мой последный) пользуются древовидной структурой. Оба запроса имеют только одну цель - найти конкретные детали (листья дерева) конкретного изделия (корень).
У вас идёт поиск от корня - строя все-все-все ветки и потом хуяк и отрезать лишнее. У меня идёт от конкретных листьев до верхушки, а там куясь и отбросить лишние. Вся разница. Что выгоднее? ХЗ - ибо не известны статистические данные.
Если детали везде одинаковые и изделий много, то ваш подымет меньше данных в итоге, если наоборот то "мой" (подход снизу вверх реже используется на практике, но по причине природы всевозможных задач).

Но если надо получить расчёты сразу для всех-всех деталей, по всем изделяиям. То тут функции не причём.
Собираем всё дерево сразу и тупо группируем.
Изерлонер
Так же помню про Ваш совет с дополнительными полями в таблицах куда будут вносится вычисляемые данные, которые будут перевычисляться при каждом изменении касающихся данных. Это наверное наиболее простой и быстрый выход.
Дерзайте.
Это один из базовых элементов проектирования - кеширование.
База сама по себе это кэшь и индексация лога, и задача админа и разрабов это выбрать правильное кеширование/индексирование под задачи.

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

Иерархический тип данных HierarchyID в одном поле хранит и парента и корень и количество уровней и можно как идентификатор использовать (т.е. вместо 4х полей - одно). Т.е. уже закещирован. И можно работать с деревом без CTE т.е. очень быстр. Если дерево редко меняется - то вообще то что доктор прописал.
Надо знать чем пользуешься, и ствол периодически чистить.
Изерлонер
Что бы из пустого в порожнее не переливать предлагаю выложить скрипты участвующих в запросе таблиц.
Бесполезно. Вы не можете понять простые вещи. Далее будет просто ахтунг.
Изерлонер
Объяснить их связи, и что должно получится на выходе.
Проблема не в том что мы не понимаем - мы понимаем намного больше чем вы можете представить. Проблема в том что вы не понимаете. И лучше научить не путаться в 3х соснах на маленьких задачках.
Изерлонер
Скрипты сделать не проблема.
Эти слова говорят об обратном. Для вас это гемор. Обычно это занимает пару минут, а не уже почти неделю.
Изерлонер
Вот как бы наполнить их данными может подскажете? Ну что бы вручную не забивать все данные в скрипт, а взять выборку какую из реальных таблиц. Это возможно сделать по простому средствами MS SQL?
Боже. В чём проблема? Находите сложный вариант одного изделия и выкладываете всё его дерево.
3 дек 13, 04:30    [15229260]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
1. Проблема не в бардаке в системе, а у вас и то что вы вываливаете на нас.

Этот подход мне знаком, и весьма любим у нас в России ... по видимому с ее основания. Нет человека - нет проблемы. То что ставят этого человека в дикие условия и приходится работать с тем что есть... это не система виновата, это человек виноват.


Mnior
2. Просто. Откройте для себя синонимы и представления.
Переименовываете название таблиц и колонок, расширяете где-что и пишите представление со старым названием таблицы и колонок. Всё работает как работало, зато теперь вы можете писать и переписывать с нормальными названиями, сохранив нам глаза.

Теперь уже вы издеваетесь. Вы ту базу видели? Я использую и синонимы и представления, только в отношении той базы это все ничем не поможет. Составные "ключи" которые и не ключи вовсе, потому как ключ по определению однозначно определяет запись в таблице, а там этого близко нет. И в таблицах могут существовать совершенно одинаковые строки из которых нужные данные получаются группировкой... На удивление это все работает, и работает почти без противоречий довольно давно и долго (с 95 года если что). Поэтому я не отрицаю эффективности такой системы, я принимаю что в жизни могут существовать разные подходы, разные школы даже. Но конкретно с современными реляционными базами данных такой подход ... весьма осложняет дело. Что бы работать с той базой у себя я сделал ответные таблицы (не представления), ввел в них суррогатные ключи (тупо по номеру строки), каждый раз скидываю файлы с новыми данными из бухгалтерии - и запускаю обновление моей ответной части... и худо бедно могу это использовать.
Вообще для решения этой "проблемы" я вижу ровно два варианта. 1. Как-то приспосабливаться к тому что есть; 2. Сделать свою собственную базу складского учета, пойти снести то старье и перевести бухгалтерию на работу с новой базой.
Второй путь пока не для меня. Остается приспосабливаться.

Mnior
Так накуя назвали вы его Index? И почему кратное ста? Зачем?Код детали это одно. Код заменяемости это другое. Нельзя смешивать понятия. Нельзя соединять не соединяемое.
Экономили на колонке? Всё равно обе колонки нужны по отдельности.

Ну, в каком то смысле это имеет отношение ... не то что к индексу, к ключу. ...Ну назвал и назвал, хоть как назови суть не меняется. 100 - это количество вариантов взаимозаменяемости (там и десяти много будет, но сделал 100). Идея пошла из того топика что я приводил, что могут быть разные варианты взаимозаменяемости. Может быть деталь А взаимозаменяемая с деталью Б, может быть деталь А не взаимозаменяемая с деталью Б но взаимозаменяемая с В и т.д. и т.п. Вряд ли я буду эту возможность использовать, но как вариант оставил на будущее... и ограничил количество этих возможностей цифрой 100 которой за глаза хватит. Что вас смущает? Это просто возможность оставленная для гибкости системы. И это не экономия на колонке, это привязка, что бы для кучи взаимозаменяемых элементов определять один - базовый. Да можно было бы сделать одно поле для взаимозаменяемости куда пихать ID базовой детали, для указания взаимозаменяемости. Но вот это как раз была бы очень жесткая привязка, не учитывающая что в одном узле детали А и Б могут быть взаимозаменяемы, а в другом нет.

Mnior
Зачем вы всё в кучу свалили?! Это самое плохое что делается. Это программисты так любят обобщать иногда. На деле должно быть строго по Предметной Области (ПО).

Может потому что на первых порах мне помогал именно программист? Когда все начиналось я пытался в самом начале делать все в отдельных таблицах. Материалы отдельно, запчасти отдельно... Была такая каша что то что вы сейчас видите идеалом стройности и не противоречивости системы покажется.
Опять же, я не отрицаю возможности разных подходов к решению задачи. Предложите пожалуйста свой красивый и понятный любой ... домохозяйке вариант схемы для описания изделия состоящего из агрегатов, узлов, подузлов, деталей ... и материалов (и не забыть еще выделить ГСМ в отдельную категорию, так как в предметной области ГСМ стоит особняком) могущих применяться на каждом уровне этой иерархии. Я не подначиваю, мне действительно интересно как еще можно было это реализовать, что бы избежать множества проблем при дальнейшей разработке системы.

Mnior
Не вижу проблем в предметной области. Проблема в вас.
Я помню. Убрать меня - все проблемы сразу решатся.

Mnior
Почему-то уверен что вы не делали не торопясь и вдумчиво. И следовательно вы не можете говорить что "при пожаре не до красоты".


Не торопясь и вдумчиво возможно когда у тебя за плечами багажа достаточно. А если никакого опыта ни знаний, то выбирать особо не приходится. Что изучил тут же и применил, к месту оно или не к месту (это как раз про эксперименты про которые вы далее пишете). Вот на текущем этапе я уже делал бы все несколько по другому, на основе того что узнал за прошедший год. А еще через лет пять все вообще иначе будет. Будет масса наработанных вариантов, паттернов и можно будет продумывать что и как лучше и эффективнее применить в том или ином конкретном случае.

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

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

Mnior
Настоящий технарь, это не тот что тушит чужой пожар, не зная как, настоящий технарь делает своё и у себя на уме, чужой пожар это поле для применения навыков и постановки своих экспериментов.

Ну точно я. Вы понимаете, мне не столько интересна работа "нормировщика" ... она вообще скушна по сути. Огромный интерес придает возможность экспериментировать с данными, создавать инструменты для анализа этих данных. Из кучи барахла и хаоса вытащить совершенно конкретные и полезные в той или иной ситуации вещи. Без баз данных .. честно я бы давно на этой должности не работал.

Mnior
Взваливать на себя ответственность которую заранее известно что не подымешь - это безответственно.
Дык ведь тяну. Не тянул бы давно бы пнули у нас с этим быстро. А базы данных это вообще чисто моя личная инициатива - руководству на это вообще наплевать.

Mnior
Да и эффективность никому не нужна. Можно зарабатывать на распилах - меньше гемора.

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


Mnior
Работа работой, а про обучение не забывайте - это отличное капиталовложение. Главное чтоб у начальства не было альтернатив, особенно у такого.


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


Mnior
Не забывайте что система живёт и меняется, а не - сделал и работает вечно. Так и сдыхают системы - от неповоротливости.

Мое предприятие "живет" 25 лет... и за это время не очень много чего изменилось. ... Изменилось разве только к худшему.
3 дек 13, 04:52    [15229269]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Да и не судите в конце концов строго. А то Вы так уже сразу судите - что это не моё. Только из-за того что такой бардак в системе и такой подход у меня. Специалист, профессионал растет на задачах от простого к сложному, постепенно. А мне сходу, без промежутков свалилась задача повышенной сложности. Это как третьеклассника заставить диффуравнения решать. Даже с огромной мотивацией бардак будет. Не потому что он не способен, может просто пока еще не дорос.
3 дек 13, 05:37    [15229278]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Неа. Не угадали.
Там всё рабочее, откоментировать не дрова возить, щёлк и готово. Это намёк что вы на столько не уделяете время нам показать что либо, что на тех единичных данных что вы выложили - это срока не имеет смысла (там везде NULL).


Не пойму что я такое выкладывал :( Ну даже допустим, да в данном конкретном случае для iElementID = 1 действительно нуль. Потому что данный конкретный элемент - материал, у материала нет количества на изделие, а есть только норма расхода на изделие.

Mnior
Что-то я не вижу там агрегаток. Или это количество деталей в изделии. Самое непонятное, что смотрится только на родителя, а от CTE обычно ожидается цикличность (родитель-родитель-...), поэтому я сразу вынес, чтобы показать и не запутать остальных (как обычно девиз - не смешивать понятия).


Так Вы же сами убрали это "барахло" из рекурсии, у меня она изначально там и была decNodeElementCntSumOnNode называется. И с цикличностью все в порядке было. От него и количество всех узлов на изделии считалось decNodeCnt.

Mnior
Если нет, тогда как рассчитывать норму расхода? (типа заменяемые детали A1 и A2 имет в узле нормы N1 и N2. И что? А если я буду ставить только A2?)


Значит и будет расчитываться с учетом замены только А2. Это же нормы, план. Я не могу в плане предусмотреть в какой именно комплектации прийдет изделие на ремонт. Поэтому в норматив пишу все элементы и узлы со своими нормами. Но если пришло изделие в конкретной комплектации, то и будет идти расчет по данной конкретной комплектации, за минусом тех узлов которые уже точно на данном изделии не будут устанавливаться.

Mnior
Вы тормозите (или у вас система ахтунг). И к тому же, откуда дубли - у листа один родитель, у которого тоже один родитель. Нет разницы как обходите дерево. Если собирать дерево сверху то тоже "дублируется" - выходите из корня не несколько узлов с той же деталью.


Я торможу и скриплю мозгами. И система далека от идеала. Но...Вы смеетесь надо мной? С какой стати "у листа один родитель"? Переходя на предметную область - с чего Вы решили что подшипник А может быть установлен ТОЛЬКО на один узел (родитель) и не может входить в состав других (родителей)? Да у конкретного подшипника, стоящего в одном месте один родитель и четкая линия до корневого элемента. У другого подшипника другой, и такая же четкая линия. ...Но ... по номенклатуре это же один и тот же подшипник.


Mnior
Запустите [Parents] отдельно - это все родители для всех узлов. Две связки связывают изделие с деталью (рекурсия связывает всю линию родителей).


Не вижу. Там и родители и элементы... а корневых изделий не вижу. Вообще корневые изделия у меня определяются по отсутствию Parentа.
iElementID_Parent is Null

В результатах же вашего запроса по
iElementID_Parent is Null
куча элементов в том числе не являющихся корневыми.
3 дек 13, 06:57    [15229335]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
StarikNavy
Member

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

вы бы лучше не тратили время на оправдание, и на самозащиту.
Mnior конечно чересчур строговат, но лучше попытаться понять и взять полезное, чем тратить время на переругивание и никому ненужные историко-социальные интроспекции
3 дек 13, 10:15    [15229809]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Да нет никакого переругивания, есть взаимонепонимание. Я честно пытаюсь разобраться, последний запрос и так и сяк уже вращаю практически весь день, даже на работу забил. Ну не то что-то. Капитально не то.
3 дек 13, 10:48    [15230036]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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

Вот такой вот вариант дает результат похожий на правду:
DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4;

WITH NodeLevel AS 
		(SELECT     iNodeElementID, 
					iElementID AS iElementID_Root, 
					iElementID_Parent, 
					iElementID, 
					decNodeElementCnt, 
					CAST(ISNULL(decNodeElementCnt, 0) AS decimal(8, 3)) AS decNodeElementCntSum
		FROM         dbo.tblNodeElement AS nd
		WHERE     (iElementID_Parent IS NULL)
UNION ALL
		SELECT		ne.iNodeElementID, 
					NL.iElementID_Root, 
					ne.iElementID_Parent, 
					ne.iElementID, 
					ne.decNodeElementCnt, 
					CAST(ISNULL(NL.decNodeElementCnt, 0) * ISNULL(ne.decNodeElementCnt, 0) AS decimal(8, 3)) AS decNodeElementCntSum
		FROM        dbo.tblNodeElement AS ne INNER JOIN
                    NodeLevel AS NL ON ne.iElementID_Parent = NL.iElementID)
   
  
		Select	Sum (Case When iContractorID =@iContractorID 
						Then decZehNorm * IsNull(NullIf(decNodeElementCntSum,0),1)/IsNull(NullIf(decNodeElementCnt,0),1)
						Else 0 End)	SumZeh,
				SUM(decZehNorm*IsNull(NullIf(decNodeElementCntSum,0),1)/IsNull(NullIf(decNodeElementCnt,0),1) )		SumIzd
		From	NodeLevel NL 
		Join	tblZehNorm ZN ON NL.iNodeElementID = ZN.iNodeElementID
		Where	iElementID_Root = @iElementID_Root and iElementID = @iElementID


правда похерил взаимозаменяемость, но пока на данном этапе можно пренебречь.
За вот это вот:
IsNull(NullIf(decNodeElementCntSum,0),1)/IsNull(NullIf(decNodeElementCnt,0)
прошу сильно не пинать. Сам вижу что не красиво.
decNodeCntSum - суммарное количестов деталей на издели до уровня данного узла. Считается рекурсивно. Что бы узнать количество узлов делю на количество деталей в узле - получаю количество узлов.
3 дек 13, 11:42    [15230462]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
За CAST в рекурсивном запросе тоже отвечу. Без него идёт не совпадение типов данных. (хотя в первой части запроса он таки лишний).
3 дек 13, 12:12    [15230768]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
+ Изерлонер
Изерлонер
Этот подход мне знаком, и весьма любим у нас в России ... по видимому с ее основания. Нет человека - нет проблемы. То что ставят этого человека в дикие условия и приходится работать с тем что есть... это не система виновата, это человек виноват.
Ну отмазываться что виновата система - тоже любима на подсоветском пространстве.
И одно другому не противоречит, в том что виноват человек частично и заслуга системы, образование, родители, генетика, история.
Только это не повод не посмотреть на себя критически. Ибо изменение системы начинается с изменением себя.
Изерлонер
Я использую и синонимы и представления, только в отношении той базы это все ничем не поможет.
1. Уже не верю.
2. Какая разница какая база. Сиснонимы можно и на чужие базы. Более того, часто лучше обращаться не напрямую, а через синонимы.
3. Вы как раз пишите запрос для своей базы и для своих таблиц, так что не надо ляля.
Изерлонер
Составные "ключи" которые и не ключи вовсе, потому как ключ по определению однозначно определяет запись в таблице, а там этого близко нет. И в таблицах могут существовать совершенно одинаковые строки из которых нужные данные получаются группировкой... На удивление это все работает, и работает почти без противоречий довольно давно и долго (с 95 года если что).
Это всё нормально обыгрывается. Даже половина случаев когда есть противоречия. Было бы желание менять, а вы скулите по каждой мелочи.
Изерлонер
Поэтому я не отрицаю эффективности такой системы
Не надо приводит в доводы что тормозит ваша часть от плохой системы в других местах.
Изерлонер
Но конкретно с современными реляционными базами данных такой подход ...
Повторяю, вы не можете этого говорить. Половина вашего представления ложно, ибо вы не технарь и вы не спец, вы не знаете решений и вы не имеете представления о computer sience и её законов. Так что ваши утверждения вызывают только умиление и смех.
Изерлонер
Что бы работать с той базой у себя я сделал ответные таблицы (не представления), ввел в них суррогатные ключи (тупо по номеру строки), каждый раз скидываю файлы с новыми данными из бухгалтерии - и запускаю обновление моей ответной части... и худо бедно могу это использовать.
FacePalm.jpg
Изерлонер
1. Как-то приспосабливаться к тому что есть; 2. Сделать свою собственную базу складского учета, пойти снести то старье и перевести бухгалтерию на работу с новой базой.
1. Скудоумие.
2. Глухота. (Чукча пяйсатель, чукча не читатель.)
Изерлонер
Ну назвал и назвал, хоть как назови суть не меняется.
Вы адекватны? Сомневаюсь.
Изерлонер
100 - это количество вариантов взаимозаменяемости
Вы думаете мы тут тупые. Всё ровно наоборот, пишу это в 5й раз.
Изерлонер
Идея пошла из того топика что я приводил, ...
Название с идеей не имеет отношение. Идеи чисты, а реализация говно и неправильно. Такое не надо делать .. хотя уже писал, но вы глухи.
Изерлонер
Что вас смущает?
Я же бл?*:!, написал же. Прочитайте ещё раз внимательно.
Дело в том что вы путаете людей и сами запутываетесь. Вот аргумент, а не то что это тормозит запрос. Вы это понимаете?!
Но вы 100% гуманитарий, вы просто проигнорировали что вы не поняли. Ну напишу я опять тоже самое, вы же всё равно пропустите мимо ушей. Тогда зачем?
Изерлонер
Это просто возможность оставленная для гибкости системы. И это не экономия на колонке, это привязка, что бы для кучи взаимозаменяемых элементов определять один - базовый.
Оменно. Что вводится понятие "код заменяемых деталей данного узла". Т.е. два понятия "код детали" и "код заменяемости деталей узла" - их нельзя смешивать. Две независимые колонки. Связи только идентичных по смыслу колонок ("код детали" = "код детали"; "код заменяемости деталей узла" = "код заменяемости деталей узла"). И фиолетово, как они коррелируют по значению, хоть 1/100 хоть 1/1000 хоть совершенно не коррелируют (своя секвенция)
Изерлонер
Материалы отдельно, запчасти отдельно...
Если это правда, что я не верю. То это было замечательно.
Изерлонер
Была такая каша что то что вы сейчас видите идеалом стройности и не противоречивости системы покажется.
Плять, я просто фигею от вашего непонимания что происходит.
Вы, не специалист, не технарь, видели одну систему, вы приводите плохие решения, вы просите совета, и говорите нам такое, специалистам, которые разрабатывали очень много разнообразных систем, ещё больше видели систем, и которые понимают CS, вы делаете тут авторитарные суждения?!
Это нелепо.
Изерлонер
Опять же, я не отрицаю возможности разных подходов к решению задачи.
Вы это отрицаете словами выше.
Изерлонер
Предложите ...
Предложил, конкретно что и где сделать.
Изерлонер
в предметной области ГСМ стоит особняком
1. Если с система направленна на конкретную область и что-то является в ней обязательной частью, то это не значит что оно должно лежать отдельно в таблицах.
2. Повторяю в 3 раз, физическая структура БД подстраиваются под задачи.
3. Вы наверно даже не слышали о понятии "нормализация" в БД.
Изерлонер
могущих применяться на каждом уровне этой иерархии
В том то и дело, что нет. Знаток вы наш, с взаимоисключающими параграфами. То что нет - доказывает ваш же запрос.
Изерлонер
мне действительно интересно как еще можно было это реализовать, что бы избежать множества проблем при дальнейшей разработке системы.
Не врите себе, вам фиолетово.
Изерлонер
Убрать меня - все проблемы сразу решатся.
LOL. Где логика сынок?!
Чтобы что-то исправить, не значит удалить, значит заменить.
Но с другой стороны лучше уж одно говно, чем два говна.
Изерлонер
Не торопясь и вдумчиво возможно когда у тебя за плечами багажа достаточно.
Мифы. вдумчиво, это значит думать, не зависимо от "багажа". А багаж появляется только от думать, вы думаете редко - за тоже время меньше багажа, чаще - больше. Элементарно.
"Что не убивает нас - делает нас сильней". Вы хоть понимаете глубину это высказывания?
Изерлонер
А если никакого опыта ни знаний, то выбирать особо не приходится.
Конечно, вы же не умеете изучать.
Изерлонер
Что изучил тут же и применил, к месту оно или не к месту
У вас надо писать не "изучил", а то что "увидел" то и повторил.
Изерлонер
на текущем этапе я уже делал бы все несколько по другому, на основе того что узнал за прошедший год.
Ещё один признак гуманитария и поверхностного подхода. У технаря подходы сильно не меняются, стилистика или убираются костыли (да и то часто по другим причинам).
Изерлонер
А еще через лет пять все вообще иначе будет.
Сколько я слышал это от многих людей - но ничего не меняется. Эта психологическая ловушка будет подталкивать вас ещё очень долго.
Изерлонер
Будет масса наработанных вариантов, паттернов
Плять. Всё как по учебнику.
Программистский камень
Хотя и не так чётко как соционика, но зато детально.
Изерлонер
Ну вот как есть я
Льстите себе - вы точно 100% гарантированно не такой.
Изерлонер
Экспериментов навалом... с обдумыванием правда не всегда все так просто проходит.
LOL
Изерлонер
На некоторые грабли по нескольку раз порой наступаю, пока окончательно не убежусь что не надо этого делать.
LOL
Поцоны, он думает чтобы понять весь CTE (плохой пример) к примеру, его особенности работы, побочные эффекты и т.п.
Надо внедрить в продакшин парочку систем/вариантов. Вместо того чтобы сделать за 15 минут пару десятков разнообразных запросов.
Нэту у вас карты понятий - нету. Пусто у вас в этом, в правом полушарии. А вот списочек списка треугольников (в левом) у вас конечно же большой.

Ага, ага. Вы прям понимаете все те слова которые я пишу.
Ну конечно же они не важны и не поменяют ваше представления если вдруг вы бы поняли. Да-да.
Изерлонер
Ну точно я.
Мда. Особенностью гуманитария и работы левого полушария - не критический взгляд.
Могут увидеть чёрное в белом.
Изерлонер
Огромный интерес придает возможность экспериментировать с данными, создавать инструменты для анализа этих данных. Из кучи барахла и хаоса вытащить совершенно конкретные и полезные в той или иной ситуации вещи. Без баз данных .. честно я бы давно на этой должности не работал.
Да, вас вставлет такие вещи, как школьнега магия.
А вот почему это и как оно так получается - для вас тайна за семью печатями.
Изерлонер
Дык ведь тяну.
LOL
И поэтому вы сюда пришли на форум за советом.
Изерлонер
Не тянул бы давно бы пнули у нас с этим быстро.
LOL
Писал же выше - компетенстность усидчивость на должности. Половина людей не делают даже на половину своей работы, эффективность очень плохая. Просто ваше скудное представление что и как можно было не позволяет это видеть. А слабое - потому что вы не ставите целью видеть "как можно было бы". Вы ставите целью "забабахать" и похвалится.
Изерлонер
Не нужна эффективность, совершенно точно. Точнее нужна, но в очень специфическом виде.
И самое печальное, они правы. Реально никому ничего не нужно. Нужно что бы просто раз и было. А заморачиваться на "как", т.е. тратить время и думать и развивать "как этого добиться и добиться эффективно" - этого не нужно почти никому.

Что у вас хорошо, что вы хотите делать что-то. Да, знать как это сделать эффективно, знать почему это эффективно, знать на сколько реально это эффективно - вам мало дано.
Вам бы больше критики к себе. Что бы быть более адекватным. Если конечно хотите быть таким.
Хотя до вас это не дойдёт, вы это не сможете принять.

ИМХО.
4 дек 13, 13:36    [15238859]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Изерлонер
Да и не судите в конце концов строго. А то Вы так уже сразу судите - что это не моё. Только из-за того что такой бардак в системе и такой подход у меня. Специалист, профессионал растет на задачах от простого к сложному, постепенно. А мне сходу, без промежутков свалилась задача повышенной сложности. Это как третьеклассника заставить диффуравнения решать. Даже с огромной мотивацией бардак будет. Не потому что он не способен, может просто пока еще не дорос.
Не отмазывайтесь, всё хорошо видно. Шила в мешке не утоить.
Изерлонер
Не пойму что я такое выкладывал :( Ну даже допустим, да в данном конкретном случае для iElementID = 1 действительно нуль. Потому что данный конкретный элемент - материал, у материала нет количества на изделие, а есть только норма расхода на изделие.
Наадекват.
Тестировать, экспериметатор мой, надо на разнообразных данных, со всеми выкрутасами.
Что бы сразу всё проработать, а не воду разливать как вы это делаете.
Изерлонер
Так Вы же сами убрали это "барахло" из рекурсии, у меня она изначально там и была decNodeElementCntSumOnNode называется
И видно из запроса, что в рекурсии не достаётся предыдущее значение decNodeElementCntSumOnNode для подсчёта последующего. Значит оно к рекурсии не причём.
Возможно вы троллите, но скорее вы просто не понимаете что делаете.
И я не грохнул, я перенёс это, вынес из рекурсивной части, глазастый вы наш.

Вы на вопосросы нормально можете ответить?
Mnior
Вы обходите стороной взаимозаменяемость. Какая разница заменяется ли деталь или нет, её расход же считается одинаковым? Т.е. расход идёт на супер-изделие (абстракция объединяющая все изделия которые можно впихнуть в данный узел, оно ща у вас назвается [Index/100]), т.е. одинаков для взаимозаменяемых, т.е. привязан к узлу, т.е. "индекс" по барабану?
Если нет, тогда как рассчитывать норму расхода? (типа заменяемые детали A1 и A2 имет в узле нормы N1 и N2. И что? А если я буду ставить только A2?)
Покажите как рассчитывется норма расхода.
Я так и не могу увидеть, как норма расхода. рассчитывается. На будующее?
Для конкретного изделия? На основе конкретных его деталей?
бл?*:!, так вообще причём тут "заменяетмость"?

Каша у вас в голове.
Изерлонер
С какой стати "у листа один родитель"? Переходя на предметную область - с чего Вы решили что подшипник А может быть установлен ТОЛЬКО на один узел (родитель) и не может входить в состав других (родителей)? Да у конкретного подшипника, стоящего в одном месте один родитель и четкая линия до корневого элемента. У другого подшипника другой, и такая же четкая линия. ...Но ... по номенклатуре это же один и тот же подшипник.
Вы путаете понятия. Вы должны правильно выражаться, чтобы такой каши не было.
Подшипник - это одно понятие. Тип подшипника - это другое понятие.
Подшипник как физический объект - один, он принадлежит к одному конкретному типу подшипника. Подшипников одного типа много. Каждый подшипник стоит к конкретном одном узле. Узел принадлежит к конкретному одному типу узлов.

Есть модель - тип изделия состоящий из типов узлов содержащий типы заменяемых типов деталей.
Есть конкретное изделие (принадлежащее этому типу изделий), содержащее конкретные узлы (...) содержащее конкретные детали (...).
Эти две структуры могут даже отличаться по структуре. К примеру нет "узлов" как физическое понятия.

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

автор
Не вижу. Там и родители и элементы... а корневых изделий не вижу. Вообще корневые изделия у меня определяются по отсутствию Parentа.
+ Вы слепой
DECLARE	@tblNodeElement	TABLE (
	iElementID		Int	PRIMARY KEY
,	iElementID_Parent	Int	NULL -- FK (iElementID)
)INSERT	@tblNodeElement VALUES
 (1,NULL)
,(2,1)
,(3,2)
,(4,1)
,(5,NULL)
,(6,5)
,(7,6)
,(8,6)
,(9,7)

;WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	FROM	@tblNodeElement	P
-- Если будет неправильный план (тормозить) - разкоментить
--	JOIN	dbo.tblNodeElement	E ON P.iElementID = E.iElementID_Parent
--	WHERE	E.iElementID = @iElementID
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	FROM	[Parents]		E
	JOIN	@tblNodeElement		P ON P.iElementID = E.iElementID_Parent
)	SELECT * FROM [Parents] WHERE iElementID_Parent IS NOT NULL ORDER BY 1,2
21
31
32
41
65
75
76
85
86
95
96
97
Там все паренты, но так как мы подаём для этого отношения два значения (9[лист] и 5[корень]), то получаем что нужно.
Изерлонер
В результатах же вашего запроса по
iElementID_Parent is Null
куча элементов в том числе не являющихся корневыми.
Вы дурак? Естественно что у корнего узла нет парентов. Эти строки бесполезны. Вы их отсеиваете и я их отсеиваю:
NP.iElementID_Parent = @iElementID_Root
Вот вы гуманитарий. Для вас дерево это множество: дерево сверху вниз, дерево снизу вверх ... Вам нужно понять как оно связано между собой. Вы будете это обдумывать неделю.
Для технаря одно понятие - иерархическая структура - откуда он делает миллион выводов. Это знание автоматически даёт одновременно всё многообразие представлений и записей со всеми свойствами, неважно какой язык представления и какие частности. Это функция правого полушария - видеть сразу всё и мгновенно, без рассуждений.

Изерлонер
есть взаимонепонимание
Вот не надо. Есть непонимание с вашей стороны и недоговорки.
Вы не понимаете функциональщины психотипов и "игры в двое ворот". Это не одинаковое число забитых мячей каждой команды в каждые ворота по отдельности. Это одинаковое общее количество мячей во все ворота.
Иррационал больше думает и больше понимает. Рационал больше делает и больше получает. Профит типа условно "одинаков" (качества "товара" разное).

Так что по пониманию тут вы не правы. Каждому своё.
Изерлонер
За CAST в рекурсивном запросе тоже отвечу. Без него идёт не совпадение типов данных.
Опять вы считаете нас тупыми. Мы что думаете не знаем и не видим этого когда читаем CTE?!
Это вы не видите, вам надо нарваться на это проблему и потом героически через неё перескочить. Вы же не задумываетесь почему и отчего эта проблема, и о чём она может говорить. Это уходит на второй план у вас - отложив самообучение.
Изерлонер
Вот такой вот вариант дает результат похожий на правду
Хотите учиться - читайте что пишут другие. Попытайтесь понять что пишут другие. Хотя вам это сложно, это для вас мука, копаться в чужих мыслях, ибо свои - это проблема для вас.
Вкуривайте дальше. Поработайте над собой, хотя это и мучительно для вас.
4 дек 13, 14:38    [15239522]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Может вам так понятнее?
DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4

;WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	FROM	dbo.tblNodeElement	P
-- Если будет неправильный план (тормозить) - разкоментить
--	JOIN	dbo.tblNodeElement	E ON P.iElementID = E.iElementID_Parent
--	WHERE	E.iElementID = @iElementID
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	FROM	[Parents]		E
	JOIN	dbo.tblNodeElement	P ON P.iElementID = E.iElementID_Parent
)
	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID
			THEN ZN.decZehNorm * X.decNodeCnt
			ELSE 0 END)			AS ZehNormSum
	,	Sum(ZN.decZehNorm * X.decNodeCnt)	AS IzdNormSum
	FROM	dbo.tblNodeElement	NE
	JOIN	dbo.tblZehNorm		ZN ON NE.iNodeElementID	= ZN.iNodeElementID
--LEFT	JOIN	dbo.tblElement		EP ON EP.iElementID	= NE.iElementID_Parent
--	JOIN	dbo.tblElement		EE ON EL.iElementID	= NE.iElementID
CROSS APPLY (SELECT	
	1	--	IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)	-- ?
			)	X (decNodeCnt)
	WHERE	NE.iElementID = @iElementID
	AND	Exists(	SELECT	*
			FROM	[Parents] NP
			WHERE	NP.iElementID		= NE.iElementID_Parent
			AND	NP.iElementID_Parent	= @iElementID_Root)
4 дек 13, 15:26    [15239893]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Вы прям настоящий Гуру. Насквозь всё видите... и судите.
Ваш опыт позволяет вам судить об уровне моих знаний, но не даёт вам права судить обо мне и моих мотивах в человеческом плане. Вы ошибаетесь.
Да, возможно я буду ещё неделю разбираться в тех запросах что вы привели, пытаясь понять что же вы пытались сделать. Это плохо? Что лучше разбираться, пусть тяжело и долго и всё же разобраться, или забить на все?
Вы так хвалитесь своим опытом попутно унижая меня (да знаю я что такое нормализация елы–палы, и вот эта вся идея с „индексами"... была другая идея с отдельными таблицами тех самых супер– изделий, не сработала та идея, еще больше путаницы) что забываете о результате. Как же так? Гуру, в совершенстве знающий CS делает запрос выдающий не верные данные. Чего стоят тогда все ваши громкие заявления?
Здоровья вам. В том числе душевного.
4 дек 13, 16:38    [15240705]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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

USE [master]
GO
/****** Object: Database [TMPBASE] Script Date: 12/04/2013 23:45:12 ******/
CREATE DATABASE [TMPBASE] ON PRIMARY
( NAME = N'TMPBASE', FILENAME = N'C:\Program Files (x86)\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\TMPBASE.mdf' , SIZE = 9216KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON
( NAME = N'TMPBASE_log', FILENAME = N'C:\Program Files (x86)\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\TMPBASE_log.ldf' , SIZE = 10176KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO
ALTER DATABASE [TMPBASE] SET COMPATIBILITY_LEVEL = 100
GO
IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
begin
EXEC [TMPBASE].[dbo].[sp_fulltext_database] @action = 'enable'
end
GO
ALTER DATABASE [TMPBASE] SET ANSI_NULL_DEFAULT OFF
GO
ALTER DATABASE [TMPBASE] SET ANSI_NULLS OFF
GO
ALTER DATABASE [TMPBASE] SET ANSI_PADDING OFF
GO
ALTER DATABASE [TMPBASE] SET ANSI_WARNINGS OFF
GO
ALTER DATABASE [TMPBASE] SET ARITHABORT OFF
GO
ALTER DATABASE [TMPBASE] SET AUTO_CLOSE OFF
GO
ALTER DATABASE [TMPBASE] SET AUTO_CREATE_STATISTICS ON
GO
ALTER DATABASE [TMPBASE] SET AUTO_SHRINK OFF
GO
ALTER DATABASE [TMPBASE] SET AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE [TMPBASE] SET CURSOR_CLOSE_ON_COMMIT OFF
GO
ALTER DATABASE [TMPBASE] SET CURSOR_DEFAULT GLOBAL
GO
ALTER DATABASE [TMPBASE] SET CONCAT_NULL_YIELDS_NULL OFF
GO
ALTER DATABASE [TMPBASE] SET NUMERIC_ROUNDABORT OFF
GO
ALTER DATABASE [TMPBASE] SET QUOTED_IDENTIFIER OFF
GO
ALTER DATABASE [TMPBASE] SET RECURSIVE_TRIGGERS OFF
GO
ALTER DATABASE [TMPBASE] SET DISABLE_BROKER
GO
ALTER DATABASE [TMPBASE] SET AUTO_UPDATE_STATISTICS_ASYNC OFF
GO
ALTER DATABASE [TMPBASE] SET DATE_CORRELATION_OPTIMIZATION OFF
GO
ALTER DATABASE [TMPBASE] SET TRUSTWORTHY OFF
GO
ALTER DATABASE [TMPBASE] SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE [TMPBASE] SET PARAMETERIZATION SIMPLE
GO
ALTER DATABASE [TMPBASE] SET READ_COMMITTED_SNAPSHOT OFF
GO
ALTER DATABASE [TMPBASE] SET HONOR_BROKER_PRIORITY OFF
GO
ALTER DATABASE [TMPBASE] SET READ_WRITE
GO
ALTER DATABASE [TMPBASE] SET RECOVERY SIMPLE
GO
ALTER DATABASE [TMPBASE] SET MULTI_USER
GO
ALTER DATABASE [TMPBASE] SET PAGE_VERIFY CHECKSUM
GO
ALTER DATABASE [TMPBASE] SET DB_CHAINING OFF
GO
USE [TMPBASE]
GO
/****** Object: Table [dbo].[tblNodeElement] Script Date: 12/04/2013 23:45:12 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[tblNodeElement](
[iNodeElementID] [int] NOT NULL,
[iElementID] [int] NULL,
[iElementID_Parent] [int] NULL,
[iEdizmID] [int] NULL,
[decNodeElementCnt] [decimal](8, 3) NULL,
CONSTRAINT [PK_tblNodeElement] PRIMARY KEY CLUSTERED
(
[iNodeElementID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (21875, 6020, 6000, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (41853, 1, 6005, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (42482, 1, 6011, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (42718, 1, 6015, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (42850, 1, 6016, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (43059, 1, 6020, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (43626, 1, 6023, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (47117, 1, 6000, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (54976, 6011, 6000, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (56466, 6005, 6000, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (58645, 6000, NULL, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (75556, 6023, 6000, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (79121, 6016, 6000, NULL, NULL)
INSERT [dbo].[tblNodeElement] ([iNodeElementID], [iElementID], [iElementID_Parent], [iEdizmID], [decNodeElementCnt]) VALUES (86558, 6015, 6000, NULL, NULL)
/****** Object: Table [dbo].[tblZehNorm] Script Date: 12/04/2013 23:45:12 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[tblZehNorm](
[iZehNormID] [int] NOT NULL,
[iContractorID] [int] NULL,
[iNodeElementID] [int] NULL,
[decZehNorm] [decimal](8, 3) NULL,
CONSTRAINT [PK_tblZehNorm] PRIMARY KEY CLUSTERED
(
[iZehNormID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (25148, 4, 41853, CAST(6.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (25816, 4, 42482, CAST(4.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (26052, 4, 42718, CAST(5.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (26185, 4, 42850, CAST(5.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (27006, 4, 43626, CAST(40.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (31234, 6, 47117, CAST(10.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (31238, 1, 47117, CAST(67.730 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (31239, 4, 47117, CAST(37.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (31240, 2, 47117, CAST(114.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (38160, 9, 47117, CAST(53.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (38561, 8, 43059, CAST(110.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (39337, 8, 47117, CAST(109.000 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (40861, 10, 47117, CAST(58.500 AS Decimal(8, 3)))
INSERT [dbo].[tblZehNorm] ([iZehNormID], [iContractorID], [iNodeElementID], [decZehNorm]) VALUES (41923, 11, 47117, CAST(27.400 AS Decimal(8, 3)))
/****** Object: ForeignKey [FK_tblZehNorm_tblNodeElement] Script Date: 12/04/2013 23:45:12 ******/
ALTER TABLE [dbo].[tblZehNorm] WITH CHECK ADD CONSTRAINT [FK_tblZehNorm_tblNodeElement] FOREIGN KEY([iNodeElementID])
REFERENCES [dbo].[tblNodeElement] ([iNodeElementID])
GO
ALTER TABLE [dbo].[tblZehNorm] CHECK CONSTRAINT [FK_tblZehNorm_tblNodeElement]
GO



Изерлонер
Вот такой вот вариант дает результат похожий на правду:
DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4;

WITH NodeLevel AS 
		(SELECT     iNodeElementID, 
					iElementID AS iElementID_Root, 
					iElementID_Parent, 
					iElementID, 
					decNodeElementCnt, 
					CAST(ISNULL(decNodeElementCnt, 0) AS decimal(8, 3)) AS decNodeElementCntSum
		FROM         dbo.tblNodeElement AS nd
		WHERE     (iElementID_Parent IS NULL)
UNION ALL
		SELECT		ne.iNodeElementID, 
					NL.iElementID_Root, 
					ne.iElementID_Parent, 
					ne.iElementID, 
					ne.decNodeElementCnt, 
					CAST(ISNULL(NL.decNodeElementCnt, 0) * ISNULL(ne.decNodeElementCnt, 0) AS decimal(8, 3)) AS decNodeElementCntSum
		FROM        dbo.tblNodeElement AS ne INNER JOIN
                    NodeLevel AS NL ON ne.iElementID_Parent = NL.iElementID)
   
  
		Select	Sum (Case When iContractorID =@iContractorID 
						Then decZehNorm * IsNull(NullIf(decNodeElementCntSum,0),1)/IsNull(NullIf(decNodeElementCnt,0),1)
						Else 0 End)	SumZeh,
				SUM(decZehNorm*IsNull(NullIf(decNodeElementCntSum,0),1)/IsNull(NullIf(decNodeElementCnt,0),1) )		SumIzd
		From	NodeLevel NL 
		Join	tblZehNorm ZN ON NL.iNodeElementID = ZN.iNodeElementID
		Where	iElementID_Root = @iElementID_Root and iElementID = @iElementID



SumZeh SumIzd
97.000000000 646.63000000


Mnior
Наадекват.

Mnior
Гуманитарий

Mnior
вы не имеете представления о computer sience и её законов.

Mnior
Может вам так понятнее?
DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4

;WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	FROM	dbo.tblNodeElement	P
-- Если будет неправильный план (тормозить) - разкоментить
--	JOIN	dbo.tblNodeElement	E ON P.iElementID = E.iElementID_Parent
--	WHERE	E.iElementID = @iElementID
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	FROM	[Parents]		E
	JOIN	dbo.tblNodeElement	P ON P.iElementID = E.iElementID_Parent
)
	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID
			THEN ZN.decZehNorm * X.decNodeCnt
			ELSE 0 END)			AS ZehNormSum
	,	Sum(ZN.decZehNorm * X.decNodeCnt)	AS IzdNormSum
	FROM	dbo.tblNodeElement	NE
	JOIN	dbo.tblZehNorm		ZN ON NE.iNodeElementID	= ZN.iNodeElementID
--LEFT	JOIN	dbo.tblElement		EP ON EP.iElementID	= NE.iElementID_Parent
--	JOIN	dbo.tblElement		EE ON EL.iElementID	= NE.iElementID
CROSS APPLY (SELECT	
	1	--	IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)	-- ?
			)	X (decNodeCnt)
	WHERE	NE.iElementID = @iElementID
	AND	Exists(	SELECT	*
			FROM	[Parents] NP
			WHERE	NP.iElementID		= NE.iElementID_Parent
			AND	NP.iElementID_Parent	= @iElementID_Root)



ZehNormSum IzdNormSum
60.000 170.000
4 дек 13, 18:01    [15241391]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Короче, не правы ни Вы ни я.
Ваш запрос обрезает корневой элемент.
Mnior
Естественно что у корнего узла нет парентов. Эти строки бесполезны. Вы их отсеиваете и я их отсеиваю:

Ошибаетесь, не бесполезны и я их не отсеиваю. А вот то что вы их отсеиваете и приводит к ошибке.

Далее, вы не учитываете что промежуточных элементов (пэрентов) может быть несколько штук на изделии (т.е. каждого по нескольку штук). Вы тупо единицу поставили, но понятно почему выборка данных такая, нафига заморачиваться. (к сожалению не досмотрел и в последней выборке decNodeCnt в таблице tblNodeElement так и осталось везде нуль. На деле везде где есть связь родителей там какое-либо число. Только у "листочков" (в данном конкретном случае) нету.)
Но и у меня с этой стороны ничего хорошего. Есть в рекурсивном запросе расчет общего количества деталей ... но "благополучно" обрезается при джойне tblZehNorm.

Пат.

Да, ваш вариант запроса без обрезки корневого элемента (как учитывать количество пэрентов надо еще подумать, но позже, работать таки тоже надо):
Declare @tblNodeElement table 
(iNodeElementID int PRIMARY KEY,
 iElementID int,
 iElementID_Parent int,
 decNodeElementCnt decimal(8, 3))
 Declare @tblZehNorm table
 (iZehNormID int PRIMARY KEY,
 iContractorID int,
 iNodeElementID int,
 decZehNorm decimal(8, 3))
  
 Insert @tblNodeElement Values 
 (21875, 6020, 6000, 1),
 (41853, 1, 6005, NULL),
 (42482, 1, 6011, NULL),
 (42718, 1, 6015, NULL),
 (42850, 1, 6016, NULL),
 (43059, 1, 6020, NULL),
 (43626, 1, 6023, NULL),
 (47117, 1, 6000, NULL),
 (54976, 6011, 6000, 1),
 (56466, 6005, 6000, 2),
 (58645, 6000, NULL, 1),
 (75556, 6023, 6000, 1),
 (79121, 6016, 6000, 3),
 (86558, 6015, 6000, 2)
 
Insert @tblZehNorm Values
 (25148, 4, 41853, 6),
 (25816, 4, 42482, 4),
 (26052, 4, 42718, 5),
 (26185, 4, 42850, 5),
 (27006, 4, 43626, 40),
 (31234, 6, 47117, 10),
 (31238, 1, 47117, 67.730),
 (31239, 4, 47117, 37),
 (31240, 2, 47117, 114),
 (38160, 9, 47117, 53),
 (38561, 8, 43059, 110),
 (39337, 8, 47117, 109),
 (40861, 10, 47117, 58.5),
 (41923, 11, 47117, 27.4)
 
 DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4

;WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	FROM	@tblNodeElement 	P
-- Если будет неправильный план (тормозить) - разкоментить
--	JOIN	dbo.tblNodeElement	E ON P.iElementID = E.iElementID_Parent
--	WHERE	E.iElementID = @iElementID
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	FROM	[Parents]		E
	JOIN	@tblNodeElement	P ON P.iElementID = E.iElementID_Parent
)
	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID
			THEN ZN.decZehNorm * X.decNodeCnt
			ELSE 0 END)			AS ZehNormSum
	,	Sum(ZN.decZehNorm * X.decNodeCnt)	AS IzdNormSum
	FROM	@tblNodeElement	NE
	JOIN	[Parents]		NP ON NP.iElementID 	= NE.iElementID_Parent
	JOIN	@tblZehNorm 	ZN ON NE.iNodeElementID	= ZN.iNodeElementID
--LEFT	JOIN	dbo.tblElement		EP ON EP.iElementID	= NE.iElementID_Parent
--	JOIN	dbo.tblElement		EE ON EL.iElementID	= NE.iElementID
CROSS APPLY (SELECT	
	1--IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)
			)	X (decNodeCnt)
	WHERE	NE.iElementID = @iElementID
	AND	NP.iElementID_Parent = @iElementID_Root or (NP.iElementID_Parent is null AND NP.iElementID  = @iElementID_Root) 
5 дек 13, 06:56    [15243339]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Ну и наконец как-то вот так:
Declare @tblNodeElement table 
(iNodeElementID int PRIMARY KEY,
 iElementID int,
 iElementID_Parent int,
 decNodeElementCnt decimal(8, 3))
 Declare @tblZehNorm table
 (iZehNormID int PRIMARY KEY,
 iContractorID int,
 iNodeElementID int,
 decZehNorm decimal(8, 3))
  
 Insert @tblNodeElement Values 
 (21875, 6020, 6000, 1),
 (41853, 1, 6005, NULL),
 (42482, 1, 6011, NULL),
 (42718, 1, 6015, NULL),
 (42850, 1, 6016, NULL),
 (43059, 1, 6020, NULL),
 (43626, 1, 6023, NULL),
 (47117, 1, 6000, NULL),
 (54976, 6011, 6000, 1),
 (56466, 6005, 6000, 2),
 (58645, 6000, NULL, 1),
 (75556, 6023, 6000, 1),
 (79121, 6016, 6000, 3),
 (86558, 6015, 6000, 2),
 (85616, 7777, 6016, 2),
 (85491, 1, 7777, NULL)
 
Insert @tblZehNorm Values
 (25148, 4, 41853, 6),
 (25816, 4, 42482, 4),
 (26052, 4, 42718, 5),
 (26185, 4, 42850, 5),
 (27006, 4, 43626, 40),
 (31234, 6, 47117, 10),
 (31238, 1, 47117, 67.730),
 (31239, 4, 47117, 37),
 (31240, 2, 47117, 114),
 (38160, 9, 47117, 53),
 (38561, 8, 43059, 110),
 (39337, 8, 47117, 109),
 (40861, 10, 47117, 58.5),
 (41923, 11, 47117, 27.4),
 (45569, 3, 85491, 2);
 
 DECLARE	@iElementID_Root	Int = 6000
,	@iElementID		Int = 1
,	@iContractorID		Int = 4;

WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	,	P.decNodeElementCnt
	FROM	@tblNodeElement 	P
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	,	Cast(IsNull(E.decNodeElementCnt, 1) * P.decNodeElementCnt as decimal (8,3))
	FROM	[Parents]		E
	JOIN	@tblNodeElement	P ON P.iElementID = E.iElementID_Parent
)
	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID
			THEN ZN.decZehNorm * NP.decNodeElementCnt
			ELSE 0 END)			AS ZehNormSum
	,	Sum(ZN.decZehNorm * NP.decNodeElementCnt)	AS IzdNormSum
	FROM	@tblNodeElement	NE
	JOIN	[Parents]		NP ON NP.iElementID 	= NE.iElementID_Parent
	JOIN	@tblZehNorm 	ZN ON NE.iNodeElementID	= ZN.iNodeElementID
	WHERE	NE.iElementID = @iElementID
	AND	NP.iElementID_Parent = @iElementID_Root or (NP.iElementID_Parent is null AND NP.iElementID  = @iElementID_Root)
5 дек 13, 11:18    [15244530]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Должен всё же поблагодарить. Благодаря вашему разбору я обнаружил существенный косяк в логике расчета норм расхода на изделие - зависимость расчёта от наличия норм расхода узлов в tblZehNorm. Найти его для меня было бы не просто, и обнаруживался бы он не часто (в «большой» таблице почти все узлы (но всё же не все) имеют свои нормы расхода).
Хотя ... откровенно говоря, ваш стиль общения мне не приятен,
по жизненными стратегиями с удовольствием пообщался бы, тема интересная. Но здесь это оффтоп.
5 дек 13, 13:04    [15245696]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Изерлонер
USE [master]
GO
/****** Object:  Database [TMPBASE]    Script Date: 12/04/2013 23:45:12 ******/
CREATE DATABASE [TMPBASE] ON  PRIMARY
Целая база для тестов? Вы с воём уме?
+ скрипт для первоначальной структуры таблц, всё ещё левые данные
USE tempdb;
GO
CREATE TABLE [dbo].[tblNodeElement] (
	[iNodeElementID]	Int
	CONSTRAINT [PK_tblNodeElement] PRIMARY KEY
,	[iElementID]		Int		NULL
,	[iElementID_Parent]	Int		NULL
--	CONSTRAINT [FK_tblNodeElement_Parent] REFERENCES [dbo].[tblNodeElement] ([iElementID])	-- Офигенски спроектированная таблица
--,	[iEdizmID]		Int		NULL	-- Не по теме
,	[decNodeElementCnt]	Money		NULL
)
CREATE INDEX [IX_iElementID] ON [dbo].[tblNodeElement] ([iElementID])INCLUDE([iElementID_Parent])
CREATE INDEX [IX_iElementID_Parent] ON [dbo].[tblNodeElement] ([iElementID_Parent])
CREATE TABLE [dbo].[tblZehNorm] (
	[iZehNormID]		Int
	CONSTRAINT [PK_tblZehNorm] PRIMARY KEY
,	[iContractorID]		Int	NULL
,	[iNodeElementID]	Int	NULL
	CONSTRAINT [FK_tblZehNorm_tblNodeElement] REFERENCES [dbo].[tblNodeElement] ([iNodeElementID])
,	[decZehNorm]		Money	NULL

) ON [PRIMARY]
GO
INSERT dbo.tblNodeElement ([iNodeElementID],[iElementID],[iElementID_Parent]) VALUES
 (21875,6020,6000)
,(41853,   1,6005)
,(42482,   1,6011)
,(42718,   1,6015)
,(42850,   1,6016)
,(43059,   1,6020)
,(43626,   1,6023)
,(47117,   1,6000)
,(54976,6011,6000)
,(56466,6005,6000)
,(58645,6000,NULL)
,(75556,6023,6000)
,(79121,6016,6000)
,(86558,6015,6000)
INSERT dbo.tblZehNorm ([iZehNormID],[iContractorID],[iNodeElementID],[decZehNorm]) VALUES
 (25148, 4,41853,  6.000)
,(25816, 4,42482,  4.000)
,(26052, 4,42718,  5.000)
,(26185, 4,42850,  5.000)
,(27006, 4,43626, 40.000)
,(31234, 6,47117, 10.000)
,(31238, 1,47117, 67.730)
,(31239, 4,47117, 37.000)
,(31240, 2,47117,114.000)
,(38160, 9,47117, 53.000)
,(38561, 8,43059,110.000)
,(39337, 8,47117,109.000)
,(40861,10,47117, 58.500)
,(41923,11,47117, 27.400)
GO
-- DROP TABLE [dbo].[tblZehNorm],[dbo].[tblNodeElement];
+ Первоначальный скрипт и скрипт для показа работы поиска снизу вверх (подправленный)
-- Данные
SELECT	*
FROM		dbo.tblNodeElement	NE
LEFT JOIN	dbo.tblZehNorm		ZN ON NE.iNodeElementID	= ZN.iNodeElementID

DECLARE	@iElementID_Root	Int	= 6000
,	@iElementID		Int	= 1
,	@iContractorID		Int	= 4;

-- Первоначальный запрос
WITH [NodeLevel] AS (
	SELECT	iNodeElementID
	,	iElementID			AS iElementID_Root
	,	iElementID_Parent
	,	iElementID
	,	decNodeElementCnt
	,	IsNull(decNodeElementCnt,0)	AS decNodeElementCntSum
	FROM	dbo.tblNodeElement AS nd
	WHERE (iElementID_Parent IS NULL)
UNION ALL
	SELECT	NE.iNodeElementID
	,	NL.iElementID_Root
	,	NE.iElementID_Parent
	,	NE.iElementID
	,	NE.decNodeElementCnt
	,	IsNull(NL.decNodeElementCnt,0) * IsNull(ne.decNodeElementCnt,0)	AS decNodeElementCntSum
	FROM	[NodeLevel]		NL
	JOIN	dbo.tblNodeElement	NE ON NE.iElementID_Parent = NL.iElementID
)	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID THEN X.Norm ELSE 0 END)	AS SumZeh
	,	Sum(X.Norm)								AS SumIzd
/*	SELECT	CASE WHEN ZN.iContractorID = @iContractorID THEN X.Norm ELSE 0 END	AS Zeh
	,	X.Norm									AS Izd
*/	FROM	[NodeLevel]	NL
	JOIN	dbo.tblZehNorm	ZN ON NL.iNodeElementID = ZN.iNodeElementID
	CROSS APPLY (SELECT decZehNorm * IsNull(NullIf(NL.decNodeElementCntSum,0),1) / IsNull(NullIf(NL.decNodeElementCnt,0),1))X (Norm)
	WHERE	iElementID_Root	= @iElementID_Root
	AND	iElementID	= @iElementID

-- Обратный вариант (по теме поиска снизу вверх)
;WITH [Parents] AS (
	SELECT	P.iElementID
	,	P.iElementID_Parent
	FROM	dbo.tblNodeElement	P
	WHERE	P.iElementID = @iElementID	-- Тупо оптимизация
UNION ALL
	SELECT	E.iElementID
	,	P.iElementID_Parent
	FROM	[Parents]		E
	JOIN	dbo.tblNodeElement	P ON P.iElementID = E.iElementID_Parent
)	SELECT	Sum(CASE WHEN ZN.iContractorID = @iContractorID THEN X.Norm ELSE 0 END)	AS ZehNormSum
	,	Sum(X.Norm)								AS IzdNormSum
	FROM	dbo.tblNodeElement	NE
	JOIN	dbo.tblZehNorm		ZN ON NE.iNodeElementID	= ZN.iNodeElementID
CROSS	APPLY (SELECT ZN.decZehNorm * 1	--	IsNull(NL.decNodeElementCnt * NL.decNodeElementCnt_Parent,1)	-- ?
				)	X (Norm)
	WHERE	NE.iElementID = @iElementID

Изерлонер
Вы прям настоящий Гуру. Насквозь всё видите... и судите.
Гуру, не гуру, не мне решать.
Видит то кто хочет видеть. Судить? Сужу поступки и поведение. А вы что не анализируете свои поступки, к примеру?
Может говорю в слух мысли по поступкам? И что? Табу? Моё хобби.
Неприятно? Ну знаете - вы столько себя пиарили, такой растакой. Я показ как это выглядит со стороны.
Или вы можете надёжно определить свою адекватность, без критики со стороны.
Будте последовательны.

Изерлонер
, но не даёт вам права судить обо мне и моих мотивах в человеческом плане
А где было "в человеческом плане"? Не надо обобщать теряя смысл: "Ой он критикует что-то в мою сторону - негодяй!"
Я говорил о поступка и стратегии поведения и их последствиях.
И вообще что значит "в человеческом плане", что за симулякры?

Изерлонер
Вы ошибаетесь.
Бессмысленное выражение.
Адекватно говорить только аргументы. Остальное бессмысленный фуфел.

Изерлонер
буду ещё неделю разбираться в тех запросах что вы привели, пытаясь понять что же вы пытались сделать. Это плохо?
А что хорошего?
Изерлонер
Что лучше разбираться, пусть тяжело и долго и всё же разобраться, или забить на все?
Я уже писал вам - подумайте о смене деятельности. Подумайте об этом неделю - больше пользы.
Изерлонер
Вы так хвалитесь своим опытом попутно унижая меня
Где я хвастаю? Это вы хвастаете.
Просто привожу цепочку рассуждений и на чём она основана. В противовес вашим.
А для вас всё что не знакомо хвастовство?!
Это стандартно для гуманитария. Они полны мифов и симулякров и не реального понимания что есть что. Малое критическое отношение к себе (функции правого полушария) и тратят мало времени на обдумывание.
Изерлонер
да знаю я что такое нормализация елы–палы
Так почему ваши таблицы дико не нормализованы.
Изерлонер
не сработала та идея, еще больше путаницы
Повторяю в сотый раз, вы не тот кто может судить что идея не сработала.
1. Потому что вы неправильно её реализовали
2. Потому что у вас нет опыта правильно её реализовать
3. Одна частная неправильная реализация не говорит что подход плохой
Логика элементарна. Чтобы не делать таких неправильных выводов.

Изерлонер
забываете о результате. Как же так? Гуру, в совершенстве знающий CS делает запрос выдающий не верные данные.
1. Вот - главное результат. Верность- неверность неважно. Как и почему - неважно. Явно видно что "рационал".
2. Будьте последовательны.
Вы не можете разобраться имея всё готовое по рукой, и при это мы, которые пишут запросы на коленке вслепую, без таблиц и данных - наобум. Показывая идею, а не работающий вариант.
Вы настолько неадекватны - что не можете этого понять.
Если вы понимаете, а прикидываетесь дурачком, чтобы поязвить?! То зачем?!

К элементам аутизма относят много явлений. Такие как некомуникабельность и неразличимость своих знаний и знаний других.
У интровертов часто первое, у рационалов второе. (ссори, принадлежность к дихотомиям пока путаю)

Запросы выдают идинаковый результат.

Изерлонер
Далее, вы не учитываете что промежуточных элементов (пэрентов) может быть несколько штук на изделии (т.е. каждого по нескольку штук).
1. Вы не понимаете главнорего. Я даже не решал вашу задачу, а просто упростил запрос, т.е. сделал преобразования эквивалентности. Не более.
2. Это вы называете нормализация? Это ахтунг.
Будет время, перепишу запрос, разбив на логические сущности.
Изерлонер
Вы тупо единицу поставили, но понятно почему выборка данных такая, нафига заморачиваться.
Повторяю, вам в 3й раз.
Не имея ни структуры, ни внятного объяснения ни данных, на которых можно догадаться что да как. Поставил 1 чтобы навести вас на мысль - где и что неясно.
Вот это непонимание дополняет ещё несколько процентов к аутизму. Хотя тут он от сложности взаимо понимания. Но ставя понимание кто какими знаниями обладал на второй план и показывает степень аутизма.
5 дек 13, 15:21    [15247033]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Изерлонер
Хотя ... откровенно говоря, ваш стиль общения мне не приятен,
Очевидно же.
Критика вообще не модна. Особенно по болевой функции. Обычно это доверяют только близким, наедине, и только когда психологически "подготовлены".
Таково развитие современного человека и его общества. Всё ещё обычные голые обезьяны, с низким уровнем сознания и адекватности, узкого стремления познания.
Культ личности повсеместен, культ знаний только у узкой прослойки.
"Интеллигенты" стараются вести себя мягко (джентлменски), обходя гипотетические острые углы. ("угодить" всем)
Узкое понятие, однобокое, или вообще не понимания что есть уважение, из чего состоит и каким бывает.

А миры восприятия реальности у разных психотипов просто немеряно разный.
5 дек 13, 15:33    [15247118]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить