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

Откуда: СФО
Сообщений: 1269
Mnior
Целая база для тестов? Вы с воём уме?


Изерлонер
... начал использовать недавно, и это как новая игрушка у ребенка - пихаю и к месту и не к месту

Эту оплошность, как вы видите, далее я исправил.

Mnior
А вы что не анализируете свои поступки, к примеру?

Не без этого. Только трудно порой не переступить грань и заняться самоедством.

Mnior
Так почему ваши таблицы дико не нормализованы.


Почему дико? Три нормальные формы вроде соблюдаются. Исключение - таблица элементов с полем взаимозаменяемости (будь она не ладна), но это именно исключение. Ну не нашел лучшего выхода, выход с таблицами суперизделий (две отдельные таблицы, связь с таблицей элементов много ко многим) была явно худшим вариантом... ну по крайней мере в моей реализации

Mnior
1. Вот - главное результат. Верность- неверность неважно. Как и почему - неважно. Явно видно что "рационал".

Жизнь заставила.

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


Наоборот, прекрасно понимаю! Это скорее ответ на ваши слова что, мол вы с огромным опытом и знаниями все сами прекрасно видите и понимаете.

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

Вы мне советуете сменить область деятельности... ну на хрена?! Я ж вообще много где успел поработать, в совершенно разных областях. То чем я сейчас занимаюсь ... я ж фактически ожил с этой работой. Я не знаю в чем тут конкретно дело, может быть в том что сам строю свою деятельность. Там где раньше работал - требовалось порой заниматься абсолютно не эффективной на хрен никому не нужной и бессмысленной работой. Здесь ... по большому счету никто ничего не понимает - главное выдай результат и все тут! И я даю, и вижу возможности повышать эффективность в разы. Эти возможности без баз данных не реализуемы, а против программистов и т.п. у руководства какое-то предубеждение. Да и против баз данных. Один из руководителей, вообще-то технически грамотный мужик - в прямую мне сказал - нахрен мне база данных? У меня не так много изделий в ремонте что бы делать базу данных, мне проще техотдел напрячь (во что выливается это напряжение я прекрасно видел изнутри и это полный писец). Вопрос не в количестве изделий, а в скорости и качестве подготовки данных по ним.... Значит занимаюсь сам. Творю и создаю. ... И вы мне предлагаете ... сменить область деятельности?
5 дек 13, 17:24    [15248182]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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

Эта задача была прекрасным упражнением. Но сейчас надо возвращаться к работе, от меня все-таки ждут результата. И этот результат ожидается не в виде базы данных или программы... А в совершенно конкретных бумагах и цифрах. И что бы получить эти бумаги и цифры мне необходимо срочно исправить самые серьезные и непосредственно влияющие на выдаваемый результат косяки в базе раз, и забить туда как можно быстрее и как можно больше данных - два (все приходится пока делать самому). На серьезные исправления, тем более структуры, увы времени... ну как всегда в общем.
5 дек 13, 17:38    [15248306]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Вот наброски модели:
+
Первоначальныая схема,
говённые данные,
предположительная модель,
преобразование старой схемы в новую,
старый запрос и
запрос для предположительной модели
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
--------------------------------------------------------------------------------
CREATE TABLE [dbo].[User] (
	[ID]		Int	NOT NULL	PRIMARY KEY
)
-- Модель
CREATE TABLE [dbo].[Product] (
	[ID]		Int	NOT NULL	PRIMARY KEY
)
CREATE TABLE [dbo].[Node] (	-- Компонока узлов продукта
	[ID]		Int	NOT NULL	PRIMARY KEY
,	[Product]	Int	NOT NULL	REFERENCES [dbo].[Product]	([ID])
,	[Parent]	Int         NULL	REFERENCES [dbo].[Node]		([ID])
,	[Count]		Int	NOT NULL	DEFAULT (1)
)
CREATE INDEX [IX_Product] ON [dbo].[Node] ([Product])
CREATE INDEX [IX_Parent]  ON [dbo].[Node] ([Parent])
CREATE TABLE [dbo].[Detail] (	-- Материалы/детали
	[ID]		Int	PRIMARY KEY
)
CREATE TABLE [dbo].[Assembly] (	-- Возможная компоновка узлов деталями
	[Node]		Int	NOT NULL	REFERENCES [dbo].[Node]		([ID])
,	[Detail]	Int	NOT NULL	REFERENCES [dbo].[Detail]	([ID])
,	PRIMARY KEY ([Node],[Detail])
)
-- Нормы расходов деталей по потребителям для каждой компановки
CREATE TABLE [dbo].[DetailConsumptionRate] (
	[User]		Int	NOT NULL	REFERENCES [dbo].[User]		([ID])
,	[Detail]	Int	NOT NULL
,	[Node]		Int	NOT NULL
,	[Rate]		Money	NOT NULL
,	PRIMARY KEY ([User],[Detail],[Node])
,	FOREIGN KEY ([Node],[Detail])		REFERENCES [dbo].[Assembly]	([Node],[Detail])
)
-- Реальные изделия
CREATE TABLE [dbo].[Article] (
	[ID]		Int	NOT NULL	PRIMARY KEY
,	[Product]	Int	NOT NULL	REFERENCES [dbo].[Product]	([ID])
,	[User]		Int	NOT NULL	REFERENCES [dbo].[User]		([ID])
)
CREATE TABLE [dbo].[Consist] (	-- наполнение
	[Article]	Int	NOT NULL	REFERENCES [dbo].[Article]	([ID])
,	[Node]		Int	NOT NULL	REFERENCES [dbo].[Node]		([ID])
,	[Detail]	Int	NOT NULL	REFERENCES [dbo].[Detail]	([ID])
,	[Count]		Int	NOT NULL	DEFAULT(1)
,	PRIMARY KEY ([Article],[Detail],[Node])
)
GO
--------------------------------------------------------------------------------
-- Преобразовние старой модели данных в новую
INSERT	dbo.[User](ID)
SELECT	DISTINCT iContractorID
FROM	dbo.tblZehNorm

INSERT	dbo.Product(ID)
SELECT	DISTINCT iElementID
FROM	dbo.tblNodeElement
WHERE	iElementID_Parent IS NULL

INSERT	dbo.Detail(ID)
SELECT	DISTINCT E.iElementID
FROM	dbo.tblZehNorm	N
LEFT JOIN dbo.tblNodeElement	E ON E.iNodeElementID = N.iNodeElementID

;WITH [Path] AS (
	SELECT	P.iNodeElementID	AS [Root]
	,	P.iElementID
	FROM	dbo.tblNodeElement	P
	WHERE	iElementID_Parent IS NULL
UNION ALL
	SELECT	P.[Root]
	,	N.iElementID
	FROM	[Path]			P
	JOIN	dbo.tblNodeElement	N ON N.iElementID_Parent = P.iElementID
)
INSERT	dbo.Node(ID,Product,Parent,[Count])
SELECT	DISTINCT N.iNodeElementID, X.iElementID, NullIf(P.iNodeElementID,R.[Root]), IsNull(N.decNodeElementCnt,1)
FROM	dbo.tblNodeElement	N
LEFT JOIN (SELECT DISTINCT*FROM [Path]) R ON R.iElementID = N.iElementID
LEFT JOIN dbo.tblNodeElement	P ON P.iElementID = N.iElementID_Parent
LEFT JOIN dbo.tblNodeElement	X ON X.iNodeElementID = R.[Root]

INSERT	dbo.[Assembly](Node,Detail)
SELECT	DISTINCT E.iNodeElementID,E.iElementID
FROM	dbo.tblZehNorm	N
LEFT JOIN dbo.tblNodeElement	E ON E.iNodeElementID = N.iNodeElementID

INSERT	dbo.DetailConsumptionRate([User],[Detail],[Node],Rate)
SELECT	N.iContractorID, E.iElementID, E.iNodeElementID, N.decZehNorm
FROM	dbo.tblZehNorm	N
LEFT JOIN dbo.tblNodeElement	E ON E.iNodeElementID = N.iNodeElementID

INSERT	dbo.Article(ID,Product,[User])
SELECT	ID,ID,4	-- ХЗ
FROM	dbo.Product

INSERT	dbo.Consist(Article,[Node],Detail,[Count])
SELECT	A.ID, E.iNodeElementID, E.iElementID, IsNull(E.decNodeElementCnt,1)
FROM	dbo.Article	A
JOIN	dbo.tblZehNorm	N ON N.iContractorID = A.[User]
JOIN	dbo.tblNodeElement E ON E.iNodeElementID = N.iNodeElementID
GO
--------------------------------------------------------------------------------
-- Показ имеющихся данных
SELECT	*
FROM		dbo.tblNodeElement	NE
LEFT JOIN	dbo.tblZehNorm		ZN ON NE.iNodeElementID	= ZN.iNodeElementID

SELECT	C.*,R.Rate,N.Parent
FROM	dbo.Consist	C
JOIN	dbo.Article	A ON A.ID = C.Article
JOIN	dbo.DetailConsumptionRate	R ON R.[User]	= A.[User]
					 AND R.Node	= C.Node
					 AND R.Detail	= C.Detail
JOIN	dbo.Node	N ON N.ID = C.Node

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

-- На чистой модели
SELECT	C.Article
,	C.Detail
,	Sum(C.[Count] * R.Rate)
FROM	dbo.Consist	C
JOIN	dbo.Article	A ON A.ID = C.Article
JOIN	dbo.DetailConsumptionRate	R ON R.[User]	= A.[User]
					 AND R.Node	= C.Node
					 AND R.Detail	= C.Detail
GROUP BY C.Article
	,C.Detail
GO
-- DROP TABLE [dbo].[tblZehNorm],[dbo].[tblNodeElement];
-- DROP TABLE [dbo].[Consist],[dbo].[Article],[dbo].[DetailConsumptionRate],[dbo].[Assembly],[dbo].[Detail],[dbo].[Node],[dbo].[Product],[dbo].[User];
Что означают каждая из переменных конкретной и точно, без возможной множественной интерпретации.
DECLARE	@iElementID_Root	Int	= 6000	-- Продукт как тип или конкретный продукт с идентификационным номером?
,	@iElementID		Int	= 1	-- Расходная деталь (конкретная модель, определённой серии)
,	@iContractorID		Int	= 4	-- Потребитель
SumZehSumIzd
97.00646.63
Каков конкретный смысл у этих двух показателей.
1. Норма расходов (в тубриках) для конкретного продукта
2. ???
Последний показатель говорит что или моя предположительная модель неверна (не угадал на койфейной гуще) или тут полный ахтунг.

В модели есть таблицы, которые не используются - но типа нужны для процесса (допустимые компоновки). Там есть модель продукта и сами продукты.
Модель продукта, как вы видите, не используется в конечном запросе.

Если вам не понятно что означает таблица-понятие спрашивайте.
Как только разберётесь - скажете, на сколько не соответствует реальной модели.
5 дек 13, 19:35    [15248949]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Изерлонер
Только у "листочков" (в данном конкретном случае) нету.)
Сколько нам ждать вразумительных сложных данных, с всевозможными выкрутасами???
Изерлонер
Пат.
Любите вы социальные игрища. Словно мы тут с вами индюки перьями меряемся.
Изерлонер
по жизненными стратегиями с удовольствием пообщался бы, тема интересная. Но здесь это оффтоп.
Да не проблема, можно поговорить, в другом месте.
Хотя вы можете просто почитать то что я вам привёл. Книжечки и темки. Хотя врядли вы это сможете.
Изерлонер
Не без этого. Только трудно порой не переступить грань и заняться самоедством.
Опять же.
У интровертов/иррационалов это обычно развивается самостоятельно, самоанализ, рефлексия - неотъемлемая часть мышления.
Изерлонер
Три нормальные формы вроде соблюдаются.
Не собдюдаются:
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
)

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

Так модель я вам показал, думайте - описывайте. Приводите нормальные данные для тестов и формулы расчёта.
Опишите на той модели - быстрее получите запрос на текущей.
5 дек 13, 21:01    [15249282]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Не собдюдаются:
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
)


С какой стати??? tblNodeElement привязана к tblElement, а никак не к себе самой!
А как еще реализовать иерархическую структуру куда можно загнать сколь угодно сборок/подсборор/узлов и т.п? Изделие состоит из агрегатов и деталей. Агрегаты состоят из сборочных единиц и деталей. Сборочные единицы состоят из сборочных единиц следующего уровня и деталей .... и т.д. Так же при ремонте на каждом уровне применяются какие либо материалы (это что касается выделения материалов в отдельную таблицу. Я даже себе представить не могу как можно с выделенной отдельной таблицей материалов распихать их применение по каждому уровню).
Вы ломаете всю схему базы данных. Я не знаю может быть схема (в моей реализации) и плоха, но у меня нет другой рабочей схемы.
7 дек 13, 18:42    [15258545]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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


К сообщению приложен файл. Размер - 146Kb
7 дек 13, 18:56    [15258585]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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

К сообщению приложен файл. Размер - 148Kb
7 дек 13, 19:44    [15258676]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Вот наброски модели:

Пока разбираюсь, выглядит любопытно. Вопрос по ходу - Составные ключи, насколько вообще допустимо их использовать? У меня по ходу общения на форуме сформировалось впечатление что составные ключи - зло. Лучше задать суррогатный, и поставить индексы/ограничения на соответствующие поля. Это не верно?

Mnior
Что означают каждая из переменных конкретной и точно, без возможной множественной интерпретации.
DECLARE	@iElementID_Root	Int	= 6000	-- Продукт как тип или конкретный продукт с идентификационным номером?
,	@iElementID		Int	= 1	-- Расходная деталь (конкретная модель, определённой серии)
,	@iContractorID		Int	= 4	-- Потребитель[/quot]

@iElementID_Root - изделие как тип. В ремонт могут приходить изделия целиком (разные типы изделий), либо отдельные агрегаты (в таком случае агрегат является конечным изделием). Например: изделие - автомобиль ВАЗ 2101. Отдельный агрегат (который может прийти в ремонт как в составе изделия, так и сам по себе): Двигатель - ВАЗ 2101

[quot Mnior]
SumZehSumIzd
97.00646.63
Каков конкретный смысл у этих двух показателей.
1. Норма расходов (в тубриках) для конкретного продукта
2. ???
Последний показатель говорит что или моя предположительная модель неверна (не угадал на койфейной гуще) или тут полный ахтунг.

Ахтунг.
SumZeh - норма расхода данной детали (номенклатура, тип) на данном изделии (тип изделия) в данном цехе (конкретный цех). не только для деталей, но и для материалов.
SumIzd - норма расхода данной детали на данном изделии (на все цеха предприятия в целом). Т.е. Сколько деталей (материалов) данной номенклатуры идет на ремонт всего изделия в целом.
Есть и еще один аналогичный показатель (только для деталей, ну может еще для узлов)
Суммарное количество деталей данной номенклатуры могущих быть на данном типе изделия. Т.е. если выше были нормы, здесь ВСЕ детали (в отдельных случаях норма = суммарному количеству деталей (детали обязательной замены), но как правило это не так).

Mnior
Как только разберётесь - скажете, на сколько не соответствует реальной модели.

Пока разбираюсь.
7 дек 13, 20:22    [15258762]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Изерлонер
Вопрос по ходу - Составные ключи, насколько вообще допустимо их использовать? У меня по ходу общения на форуме сформировалось впечатление что составные ключи - зло. Лучше задать суррогатный, и поставить индексы/ограничения на соответствующие поля. Это не верно?
Нет, не совсем верно. Составные ключи можно делать. Всё зависит от модели.

Обычно у сущности есть просто суррогатный ключ, но всё равно приходится вводить представительский, банально на название, лучше иметь код (серия). Но иногда есть не понятие, а связка. Связка часто не имеет "потомков", оно просто связывает, типа пользователь-роль (тут один ключ), и может иметь свойства (типа Hidden, Modified), но иногда нет - оно также является понятием, и если у него есть под-элементы и выступает самостоятельной единицей тогда стоит ввести и суррогатный.

В данном случае оно того не стоит. Можно ввести, но больше нагромождает. Более того, модель нестабильна, не определена (это главная причина). Тем более что можно в принципе убить таблицу dbo.Assembly, и её роль возмёт на себя сама dbo.DetailConsumptionRate.

Т.е. вверху суррогат необходим, а внизу можно и подыграть. Надо помнить главное - схема базы строится под задачи. Такая структура с составным ключём увеличивает производительность за счёт уменьшения количества таблиц в запросах (сразу есть нужная колонка).
Только в текущих версия это стало менее обязательно. Т.к. можно создавать индекс сразу на несколько таблиц (межтабличные индексы). Разве что лишние индексы занимают память и IO.
Изерлонер
@iElementID_Root - изделие как тип.
Это чётко.
Поправлю запрос на моей модели:
SELECT	A.Product
,	C.Detail
,	Sum(C.[Count] * R.Rate)
FROM	dbo.Consist	C
JOIN	dbo.Article	A ON A.ID = C.Article
JOIN	dbo.DetailConsumptionRate	R ON R.[User]	= A.[User]
					 AND R.Node	= C.Node
					 AND R.Detail	= C.Detail
GROUP BY A.Product
	,C.Detail

Изерлонер
В ремонт могут приходить изделия целиком (разные типы изделий), либо отдельные агрегаты (в таком случае агрегат является конечным изделием). Например: изделие - автомобиль ВАЗ 2101. Отдельный агрегат (который может прийти в ремонт как в составе изделия, так и сам по себе): Двигатель - ВАЗ 2101
Из этого следует что вам нужно расчитывать нормы расхода как для "Автомоблиля ВАЗ 2101", так и для "Двигатель ВАЗа 2101"? Или только для изделий целиком? (видимо для любого агрегата)
Изерлонер
SumZeh - норма расхода данной детали (номенклатура, тип)
Пишите чётче, белая сажа это ахтунг.
Изерлонер
не только для деталей, но и для материалов
Какая разница?! Пусть в строках пишутся хоть килограмы подшипников, хоть метры газа, хоть штук жидкости.
SumIzd - норма расхода типа детали на типе изделия
Правильно?
Тогда вопрос. Если это тип изделия. То причём тут заменяемость деталей?
Комплектация деталями может быть разнообразно. Для каждой комбинации рассчитывать? Но их количество растёт пропорционально факториалу заменяемости деталей.

Что есть decNodeElementCnt?
Что есть decZehNorm?

Это нормы расходов для деталей? Что это?

Как я понимаю есть два подхода в расчёте нормы расхода: графоаналитический и расчетный.
Какой у вас используется? Судя по тому что у вас описана структура продукта, то расчётный.

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

Тогда сразу вопрос, причём тут цех? Норма расхода, заложенная в модели не зависит от производства.
Там просто издержки расходов материалов из-за изношености станков или их особенностей.
Тогда получается у вас графоаналитический подход рассчёта нормы рассхода.

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

При графаналитическом в таблице dbo.DetailConsumptionRate можно убить колонку [Node] (вот и пригодился составной ключ), ибо тупо считает до кучи, сколько потрачено в целом.
Изерлонер
Есть и еще один аналогичный показатель (только для деталей, ну может еще для узлов)
Суммарное количество деталей данной номенклатуры могущих быть на данном типе изделия. Т.е. если выше были нормы, здесь ВСЕ детали (в отдельных случаях норма = суммарному количеству деталей (детали обязательной замены), но как правило это не так)
Стоп, мы ещё чётко не расписали что к чему. Суммарное количество типов деталей?
Мы говорим о расходе материалов на производство изделия? Или расхода запасных частей станков для их производства?

Всё ещё непонятно про заменяемость деталей. Есть заложенная схема продукта из конкретных материалов и конкретных деталей в конкретных узлах. Т.е. конкретные нормы расходов.
И вот допустим можно некоторые детали заменять. Тогда вводится понятие комплектация.

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

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

На данный момент моя модель, судя по всему, не подходит (надо упрощать, корректировать). Но какая правильная - зависит от ответов на выше перечисленные вопросы.
Позже поразбираюсь в ваших таблах.
8 дек 13, 03:39    [15259845]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mnior
И норма расхода рассчитывается только на конкретную комплектацию (расчётным методом), или хоть на весь завод но графаналитически, хотя назвать.
И почему это называется "нормой" не пойму - простая сумма расходов. Хотя понятно - эти бухгалтера, часто обычные лысые обезьяны гуманитарии - любят надумывать симулякров, превращая в мир в ад, обманывая себя что добавляют себе важности.
fixed
8 дек 13, 03:49    [15259848]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Из этого следует что вам нужно расчитывать нормы расхода как для "Автомоблиля ВАЗ 2101", так и для "Двигатель ВАЗа 2101"? Или только для изделий целиком? (видимо для любого агрегата)


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

Mnior
Изерлонер
SumZeh - норма расхода данной детали (номенклатура, тип)
Пишите чётче, белая сажа это ахтунг.


Меня сбивает слово "тип" в отношении детали. Номенклатура здесь более подходит. Норма расхода детали данной номенклатуры.

Mnior
SumIzd - норма расхода типа детали на типе изделия Правильно?
норма расхода детали данной номенклатуры на типе изделия.

Mnior
Тогда вопрос. Если это тип изделия. То причём тут заменяемость деталей?
Комплектация деталями может быть разнообразно. Для каждой комбинации рассчитывать? Но их количество растёт пропорционально факториалу заменяемости деталей.


Во-во. Головняк это большой. Я бы тут еще разделил взаимозаменяемость деталей и взаимозаменяемость узлов. Каждый тип изделий он же не фиксирован, идет время - какие-то агрегаты (входящие в состав изделия) модифицируются производителем, появляются новые серии и т.д. И это все один и тот же тип. Был автомобиль ВАЗ 2101, в каком нибудь 1972 году ему модифицировали трансмиссию. Была трансмиссия А, стала Б. Суть ни чем не помянялась, поменялась номенклатура и количество деталей. И таких модификаций на любом агрегате до черта. Я тут к одному нашему спецу подошел (реальный спец, технарь, но в прямую с изделиями не работает) спрашиваю как быть? Что в нормах учитывать? Он говорит - если ты попытаешься учитывать все модификации - то в конец запутаешься и сдохнешь на работе. Учитывай только последнюю модификацию.
Я бы и рад, мне же головняка меньше. Разговариваю с технологами - а что может вообще в ремонт прийти и в каком виде мы это выпускаем? В ремонт может прийти все что угодно в том числе изделия с агрегатами старых модификаций. И мы их ремонтируем и выпускаем с теми же модификациями (доработки могут быть, но могут и не быть - все по согласованию с заказчиком).
Вот отсюда пошли попытки хоть как-то все это учесть, попытался совместить ежа с ужом. Есть базовая комплектация (сам назначаю) в нее входят все агрегаты самой последнее модификации и для этой фиксированной комплектации и расчитываются все нормы (тут все четко, просматривается количество деталей каждой номенклатуры, нормы...). Но! Так как в ремонт могут прийти изделия с агрегатами ранних модификаций их тоже как то надо учитывать и показывать в нормативах. Я их и показываю. В примечании ставлю - "взаимозаменяема с..." а расчет суммарных показателей (норм и количеств) проводится так как если бы все изделие было в базовой комплектации, за исключением данного конкретного агрегата.
Ну а с взаимозаменяемостью отдельных деталей (и материалов) несколько проще если не заморачиваться (а то и там случаев таких наскрести можно что голова кругом, но это все же редко, да и нахрен никому не нужны эти тонкости... может быть кроме меня) Есть взаимозаменяемые детали например подшипник А и Б. В нормативах показываем и тот подшипник и другой с их количествами и нормами, примечание - "взаимозаменяемы", но при анализе фактического использования в ремонте - условие. Если установлен подшипник А (и выбрана вся норма/количество), то подшипник Б ставить нельзя. И наоборот.

Mnior
Что есть decNodeElementCnt?
Что есть decZehNorm?

Это нормы расходов для деталей? Что это?


decNodeElementCnt - количество деталей (или узлов... материалы здесь точно не указываются) в узле.
decZehNorm - норма расхода детали/узла (материала) на ремонт данного узла.

Mnior
Как я понимаю есть два подхода в расчёте нормы расхода: графоаналитический и расчетный.
Какой у вас используется? Судя по тому что у вас описана структура продукта, то расчётный.


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


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


Ни при чем. Нормы в руководствах задаются на изделие (агрегат), на цеха распределяю я сам (в соответствии со специализацией цехов и тем что написано о процессе ремонта в тех же руководствах.
А издержки расходов на станки и т.п. вообще не учитываются. (это все накладные расходы, которые меня никак не интересуют) Главное то что идет непосредственно на сам ремонт.

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

[quot Mnior]Стоп, мы ещё чётко не расписали что к чему. Суммарное количество типов деталей?
Мы говорим о расходе материалов на производство изделия? Или расхода запасных частей станков для их производства?С
Если Вы под суммарным количеством типов имеете ввиду сколько разнообразных типов в изделии имеется вообще, то нет. Суммарное количество детали данного типа (ну не катит здесь тип, номенклатура ближе) на изделие.
Стоят у вас свечи в двигателе автомобиля. Суммарное количество на агрегат (двигатель) - 4 шт. На изделие (автомобиль) - 4 шт. Если бы в автомобиле стояло 2 двигателя - было бы 4 и 8 соответственно.
Но это суммарное количество тех что стоят вообще. По норме при ремонте могут заменяться не все свечи, а например 2шт на двигатель. Тогда в последнем случае получим цифры 2, 4 соответственно.


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

У нас вполне себе симпатишные женщины
А почему не норма? Если для изделия в целом то норма и есть. По ней затем далее другими отделами расчитываются свои плановые показатели. Сколько изделий будем ремонтировать в следующем году, да сколько материалов/деталей необходимо закупить для ремонта. Что из этого срочно (уже сейчас) надо заказывать. Планирование сроков, закупок и т.п.
8 дек 13, 07:27    [15259900]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Изерлонер
decZehNorm - норма расхода детали/узла (материала) на ремонт данного узла.

decZehNorm - норма расхода детали/узла (материала) на ремонт данного узла в данном цехе.
8 дек 13, 07:33    [15259905]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
По поводу норм такую "крамолу" еще напишу. В ремонтном производстве на нормы в принципе наплевать. Норму подвинуть можно. Начнет орать начальник какого-нибудь цеха что ему на ремонт изделия ... спирту не хватает. Соберут комиссию, и если его доводы признают убедительными "Мамой клянусь!" - подпишут не взирая на наличие/отстутвие норм расхода.
Не так все просто конечно, все ж проверок боятся, но тем не менее, найдут основание это сделать.
Поэтому для меня конкретно, как для нормировщика есть следующие правила:
Для проверки расхода материалов ориентируюсь на нормы +/- какой-то допуск (особо жесткий допуск для ГСМ в "+" практически ничего). В случае значительного превышения этого допуска требую от начальника цеха бумажку мне на стол за подписью главного инженера - "Куда? Зачем? Основание?". Есть бумажка? Нет проблем, пропускаю. Нет бумажки - че хотите делайте - больше нормы не дам.
Для проверки расхода запасных частей самым жестким критерием является количество на изделии decNodeElementCnt. Ну не может быть на изделие выписано четыре подшипника типа А если их на всем изделии стоит две штуки. Физически не может быть.
По нормам критерий примерно такой же как и для материалов. На каждое превышение нормы - бумажка. (на деле 50/50 где-то есть бумага, где-то нет пока проверяющие не докапывались (вообще до меня пока не добирались, хотя близко были, да. У меня волосы дыбом на башке торчали), но в идеале при превышении нормы должна быть бумага, что бы прикрыть свою ж задницу)
8 дек 13, 08:06    [15259909]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Смысл суммарных показателей (норма на изделие по цеху, норма на изделие, количество деталей на изделие):
1. КОНТРОЛЬ материальных затрат на ремонт реального изделия проходящего ремонт. Это главная цель, ради неё и все танцы с бубном. Затраты списываются во внешней базе данных на изделие (в случае полноценного изделия) или на наряд-заказ в случае списания на отдельные агрегаты (а вот это конкретный такой ахтунг, с которым я очень долго боролся настаивая ОДИН агрегат – ОДИН наряд–заказ! Но добился лишь что на один наряд заказ могут быть несколько однотипных агрегатов. Проследить на какой конкретно агрегат была списана деталь пользуясь только базой данных не возможно. Но так всё равно лучше, чем когда на один наряд– заказ была масса разнотипных агрегатов — контролировать вообще ничего не реально.
Ну и соответственно суммируется расход по внешней (учетной) базе данных и сравнивается с суммарными показателями моей. Сравнивается, выдается заключение – в норме (пропустить «требование»), недобор, перебор.
2. Выдача плановых показателей на будущие периоды, выдача заданий ОМТС. Расчет цены ремонта (в части касающейся материальных затрат) для заказчиков с подробным обоснованием
8 дек 13, 10:42    [15260009]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Так модель я вам показал, думайте - описывайте. Приводите нормальные данные для тестов и формулы расчёта.
Опишите на той модели - быстрее получите запрос на текущей.

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

К сообщению приложен файл (Тестовые данные.zip - 11Kb) cкачать
8 дек 13, 17:14    [15260667]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Изерлонер
Mnior
Как я понимаю есть два подхода в расчёте нормы расхода: графоаналитический и расчетный.
Какой у вас используется? Судя по тому что у вас описана структура продукта, то расчётный.
Никакой. ... В отдельных спорных случаях может быть прямой замер ... которая уже может служить основанием и может быть включена в норматив. ... Там где норм нету сам использовал расчетный метод.
Как это никакой - это чётко граф аналитический (когда проверка делается). И расчётный что вы сами делаете.
Т.е. смешанный. Кое-где простая сумма по структукре изделия, кое где акт проверки на станке - вписываются цифры явно, без описания структуры. Но как я понимаю только для агрегата, а не "7 квадратов стали X на весь ВАЗ 2101"
Изерлонер
... например на ремонт может быть выписано что либо не потому что необходимо для ремонта, а что бы набрать затраты на ремонт. Все ведь с ног на голову сегодня поставлено, экономика рулит ) и никому мои расчеты интересны не будут в случае чего.
Покрываете конкретных людёй, хамба не обойдёт вас стороной.
Изерлонер
Mnior
Тогда сразу вопрос, причём тут цех? Норма расхода, заложенная в модели не зависит от производства.
Там просто издержки расходов материалов из-за изношености станков или их особенностей.
Ни при чем. Нормы в руководствах задаются на изделие (агрегат), на цеха распределяю я сам (в соответствии со специализацией цехов и тем что написано о процессе ремонта в тех же руководствах.
А издержки расходов на станки и т.п. вообще не учитываются. (это все накладные расходы, которые меня никак не интересуют) Главное то что идет непосредственно на сам ремонт.
Вы можете нормально отвечать на вопросы?!
Ваши ответы я не понял:
-: 2 + 2 = 4?
-: Нет! Нет! И Нет! Ни в коем случае! 2 + 2 = 4!
-: Так четыре?
-: Нет! Панимаете, я сегодня вышел на улицу и была плохая погода. А 2 + 2 будет Четыре!

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

К примеру:
- 1 + 2 + 3 + 4 = 10?
- Нет! 4 + 3 будет 7. 7 + 2 = 9, и 9 + 1 будет 10. Потому ответ 10.

Так нельзя говорить. Надо так и сказать - "Я не очень могу так считать, могу ват так". Но не пишите нет, которые может означать - "не понял", "не знаю", "ХЗ" и т.п.

"Не приём" - для меня означает, что мы вырезаем любое упоминание этого термина и эту переменную из задачи в любом виде.
Договорились?
Изерлонер
decZehNorm - норма расхода детали/узла (материала) на ремонт данного узла.
Давайте определимся в терминологии.
Давайте убирём слово "норма расхода" вообще. А просто напишем количество (для деталей - для данного узла нужно 3 подшипника типа A), состав, или затрачивается (на деталь X тратится N килограмм чугуния)
Притом неважно, для узла или для всего продукта - это тупо "количество материала".

Нет никаких справочников аля tbZehNorm. Количество прописывает или в структурной таблице, или в упрощённой - не важно.
В итоге мы получаем константную сводную таблицу: ([Продукт],[Деталь/материал],[Количество/Затраты]).
Эта таблица автоматически изменяется только в момент ввода структуры продукта/агрегата/узла (при расчётном подходе) или при акте замеров (при графаналитическом).

Расчётный метод это не только расчёт объёма материала на основании заливки, стругания болванок, сверления и т.п. А даже просто: тупое суммирование деталей.

Вы должны всегда огораживать нас от вашей кухни которая никоем образом не касается задачи. К примеру:
"Мы составляем 100500 актов затрат материалов, а потом суммируем на бумажка, а в систему вводится итоговая сумма". Вы должны так и сказать "Вводится итоговая сумма на основании реальных замеров". Мусор словоблудия не нужно. Ок?
Это раздражает.
Изерлонер
Mnior
Вы уже определитесь какой у вас. Если оба, то они независимы, хоть и ссылаются на общие таблы.
Теоретически можно использовать расчетный ...
Смешанный у вас вариант. Всё.

Изерлонер
Mnior
Изерлонер
Есть и еще один аналогичный показатель (только для деталей, ну может еще для узлов)
Суммарное количество деталей данной номенклатуры могущих быть на данном типе изделия. Т.е. если выше были нормы, здесь ВСЕ детали (в отдельных случаях норма = суммарному количеству деталей (детали обязательной замены), но как правило это не так)
Стоп, мы ещё чётко не расписали что к чему. Суммарное количество типов деталей?
Мы говорим о расходе материалов на производство изделия? Или расхода запасных частей станков для их производства?
Если Вы под суммарным количеством типов имеете ввиду ...
Вы можете всётаки не терять нить разговора и объяснить что это за зверь такой: "Ещё один дополнительный показатель", в отличие от "количество материала".
Изерлонер
ну не катит здесь тип, номенклатура ближе
Давайте без бардака.
Есть объект (конкретная машина в которая сейчас стоит на стоянке), а есть тип объекта (ВАЗ 2101 как модель автомобиля).
Объектов тип А - много. Типов А - адын, и так даже нельзя говорить.
Далее, если у вас есть тип "ВАЗ 2101 А" и "ВАЗ 2101 Б", то это два разных типа, и тогда "ВАЗ 2101" - не тип, а группа типов.
Вы можете назвать место слова "тип" - "модель", можете "номенклатура", но если но вы должны выбрать и придерживаться только одного названия и не употреблять другие.
"номенклатура" - это сленг в данном случае, а сленг посылаем на хрен - тут форум не данной тематически.

В вашем случае вы можете сделать группы моделей, но никак нашей задачи это не должно касаться вообще. Это ваша проблема, оставьте это за кадром.
Изерлонер
Но это суммарное количество тех что стоят вообще. По норме при ремонте могут заменяться не все свечи, а например 2шт на двигатель. Тогда в последнем случае получим цифры 2, 4 соответственно.
Вы должны чётко отделить производство продукта от ремонта продукта.
Это не понятия никак не пересекаются. Это разные задачи. И значения по ним разное:
1. Для производства автомобилей модели А - необходимо затратить 3 тонны чугуния.
2. Для ремонта автомобиля модели А, серия и номер XXXX....XXXXX, от такого-то числа было затрачено 3 килограмма чугуния.
3. Для ремонта автомобилей модели А, за этот месяц на этом ремонтном гараже, в среднем по больнице требовалось 3.14 килограмм чугуния.

"Норма" (понятие которое мы далее не будет употреблять) имеет место быть для производства, не для ремонта.
Может быть там у вас и употребляются одинаковые слова - но это не значит что это одно и тоже или как-то связано.
"Расчётный износ детали" - это другая опера. Это тесты, это замеры и состав автомобиля тут не причём совершенно. Это просто абстрактные константы в вакууме.
Изерлонер
По ней затем далее другими отделами расчитываются свои плановые показатели. Сколько изделий будем ремонтировать в следующем году, да сколько материалов/деталей необходимо закупить для ремонта. Что из этого срочно (уже сейчас) надо заказывать. Планирование сроков, закупок и т.п.
В том то и дело, этим словом называют разные вещи и оно не звучит для обывателя.

Для производства детали А станок потребляет 314 грамм чугуния. За месяц сгорает 15 свечек у автомобиля модели А.
Это разные вещи. Обусловленные разными процессами. Одно дело состав агрегата и как он делается, и какой станок, а другое дело, мастерство и степень экплуатации автомобиля в текущих условиях.

И вы так и не сказали область что мы рассчитываем - ремонт или производство. Пошли в абстракции. Вместо того чтобы определять чётко конкретику и идти дальше.
Изерлонер
По поводу норм такую "крамолу" еще напишу. ...
Как это относится к задаче? Это голый спам и словоблудие.
автор
Для проверки расхода запасных частей самым жестким критерием является количество на изделии decNodeElementCnt. Ну не может быть на изделие выписано четыре подшипника типа А если их на всем изделии стоит две штуки. Физически не может быть.
Это совершенно разная задача. Одно дело рассчитать сумму затратов на производство.
Другое контролировать процесс. Контролировать можно 100500 способами, включая контроль предельных допустимых значений.
У вас походу целый комплекс задач. И бардак в голове.
Изерлонер
На каждое превышение нормы - бумажка.
И занимаетесь вы маразмом, и постановка задачи маразматическая.
Изерлонер
Смысл суммарных показателей (норма на изделие по цеху, норма на изделие, количество деталей на изделие):
Средняя температура по больнице - это идиотизм. ТЧК.
Изерлонер
1. КОНТРОЛЬ материальных затрат на ремонт реального изделия проходящего ремонт.
1. Как много вам пришлось писать чтобы написать самое важное. То с чего надо было начать топик.
2. Контроль заключается не в расчёте "средней по больнице". А учёте самого процесса ремонта.
Изерлонер
ОДИН агрегат – ОДИН наряд–заказ!
Вот так программисткие заскоки влияют на процесс. Можно организовать как хочешь, главное правильно модель запроектировать. А вы проектировать всякое не умеете.
Да, нужно ставить ограничения, для контроля, но тут явно видно что всё хотите свести к одной строке в табле, и вход и выход.

Из описанного могу сказать: Вас специально подобрали на ваше место - как лучшую кандидатуру чтобы можно было сохранить бардак на предприятии, чтобы спокойно воровать дальше. А если что - вами и прикроются.
ИМХО.

Изерлонер
В вашей модели у узлов не может быть норм расхода?
FacePalm.JPG
Как опишите постановку задачи так и будет считаться. Нет постановки нет модели. Из вас тяжело добиться вразумительного ответа, чтобы расписать модель. А вас ещё поставили как разработчика.
Нет слов.

С таким подходам вам только в форум работа. И сдерут с вас нехило.
9 дек 13, 21:57    [15267418]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Вам нужно просто завести в нужную древовидную структуру данных (в общем смысле, а не Parent - ID). Вводить показания реальных потреблений и через OLAP смотреть по нужным разрезам.
Сейчас там есть и предсказания и среднее по больнице и нормы и всё такое.

Для контроля нужны описания структуры изделий. Можно аж вводимые данные проверять на крайние условия, или отдельно учитывать поломка деталей во время ремонта.
Т.е. просто отражать весь процесс в цифре.
Учитывать материалы на выкидывание (заменённые детали). Замеры выборочного контроля. Учёт пользователей.
Ну и всё такое.
9 дек 13, 22:46    [15267632]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
+
Mnior
У вас походу целый комплекс задач.

Совершенно верно. И нормирование малая часть этих задач. Но я считаю ее ключевой. В нормальных условиях такими задачами отдел занимается, а то и не один.
Mnior
И бардак в голове.

И это верно, но не вполне.
По остальному напишу позже. После очередного запара у меня действительно бардак в голове, мысли в порядок привести надо.
10 дек 13, 08:06    [15268356]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Mnior
Как это никакой - это чётко граф аналитический (когда проверка делается). И расчётный что вы сами делаете.

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

Mnior
Давайте убирём слово "норма расхода" вообще. А просто напишем количество (для деталей - для данного узла нужно 3 подшипника типа A), состав, или затрачивается (на деталь X тратится N килограмм чугуния)
Притом неважно, для узла или для всего продукта - это тупо "количество материала".


Норма расхода она и есть норма. Это плановый показатель. Убрать можно, но Вы потом в количествах не запутаетесь? Количество материалов/деталей затрачиваемых на ремонт план/факт. Количество деталей установленных на агрегате. ...

Mnior
"номенклатура" - это сленг в данном случае, а сленг посылаем на хрен - тут форум не данной тематически.


Пусть будет тип.

Mnior
"Норма" (понятие которое мы далее не будет употреблять) имеет место быть для производства, не для ремонта.


Расскажите это издателям ремонтной документации.

Mnior
Для производства детали А станок потребляет 314 грамм чугуния. За месяц сгорает 15 свечек у автомобиля модели А.
Это разные вещи.


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

Mnior
И вы так и не сказали область что мы рассчитываем - ремонт или производство.


Ремонт.

Mnior
Средняя температура по больнице - это идиотизм. ТЧК.


Не я это придумал... но мне это надо каким-то образом реализовывать.

Mnior
Вот так программисткие заскоки влияют на процесс.


При чем здесь заскоки. Как проконтролировать на какое изделие была установлена деталь если она выписана на группу деталей? ... и я не программист.

Mnior
Вас специально подобрали на ваше место - как лучшую кандидатуру чтобы можно было сохранить бардак на предприятии, чтобы спокойно воровать дальше. А если что - вами и прикроются.
ИМХО.

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

Mnior
А вас ещё поставили как разработчика.
Нет слов.


Не ставили меня разработчиком. Нужно было заткнуть кем-нибудь дырку, под руку я попался. ...и мне вдруг эта работа оказалсь сильно интереснее предыдущей. То что у большинства работников вызывает сильное желание уснуть ... я обрабатываю с интересом. ...Хотя даже этого интереса бывает мало что бы сдержаться и не положить заявление об увольнении начальнику на стол... Разработка - это моя личная инициатива.
[/quot]
10 дек 13, 09:03    [15268545]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Изерлонер
расчитывали, статистическими методами, графоаналитическими методами.

Опечатался. Расчётными методами, графоаналитическими методами.
Короче, расчёт непосредственно самих норм (для каждой детали в изделии) это не моя задача. Моя задача использовать то что уже есть в "бумажном" варианте.
Надеюсь с этим задача упрощается?
10 дек 13, 11:30    [15269556]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Изерлонер
Как проконтролировать на какое изделие была установлена деталь если она выписана на группу деталей?

блин, точно спать надо. На группу изделий конечно.
10 дек 13, 11:39    [15269631]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Я не понимаю смысла таблицы Article в вашей схеме. Я вижу что в ней определяется взаимосвязь цеха и изделия, но зачем (или почему именно так) не понятно.
И давайте действительно определяться с понятиями. Могу попытаться более менее корректно описать требования, что есть и что нужно. Насколько подробно надо описывать?
10 дек 13, 18:22    [15273325]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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

если вы решите уйти из темы, прошу просто скажите об этом, не молчите.
10 дек 13, 18:27    [15273338]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Изерлонер
Member

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

если вас смущает понятие норма в отношении ремонта, предлагаю замену - плановый расход материалов/запчастей на ремонт, в противовес фактическому расходу.
10 дек 13, 18:39    [15273398]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить выполнение запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Изерлонер
если вы решите уйти из темы, прошу просто скажите об этом, не молчите.
Никуда я не ушёл, просто вы медленно пережёвываете, а точнее просто молча пропускаете что не поняли. Я столько написал - а всё как в песок ушло.
Не думаю что будет какой либо результат от разговора.

Изерлонер
Я не понимаю смысла таблицы Article в вашей схеме.
Я два раза писал, что та схема возможно не актуальна.
Править её не получается из-за непонятности целей и отсутствия внятного ТЗ, и уже совсем не интересно заниматься откровенно бредовой задачей, вешедшей за рамки рациональности.
Article изначально было как "реальное изделие"

Изерлонер
Могу попытаться более менее корректно описать требования, что есть и что нужно. Насколько подробно надо описывать?
Тема перешла из разбора принципов проектирования в проектирование конкретной задачи.
Бредовость задачи не имеет смысла, если бы мне предложили разработать, я бы загнул цены раз в 5ть. Пустая трата времени.
Поэтому и предложил вам идти на форум "работа".

Изерлонер
Норма расхода она и есть норма
Какова "норма потребления" бутербродов с красной икрой?
Каково наказание за не выполнение этой нормы среднестатистического жителя Африки?
Это симулякр.

Изерлонер
Расскажите это издателям ремонтной документации.
Повторяю в N раз - нам до фени с кем вы там общаетесь, но не надо со здоровой головы на больную, пусть это там и останется.

Изерлонер
автор
Mnior
Для производства детали А станок потребляет 314 грамм чугуния. За месяц сгорает 15 свечек у автомобиля модели А. Это разные вещи.
Это и ежику понятно.
Если было понятно, это бы отражалось в схеме разними элементами или чёткостью в разговоре.
Изерлонер
Ремонт.
Какие быстрые темпы внятного объяснения задачи. И сколько лет мне вытягивать это клещами?

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

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

Сперва распишите в 3-7 предложений (без воды и чётко) суть задачи, так чтоб это понял любой реальный технарь, не читавший этого бреда. Типа: "Система учёта расхода деталей/материалов для ремонтных цехов и контроля допустимых их значений на основе структуры ремонтируемых изделий ...", раскрывая суть "учёта расхода".
Вот вам цель, вот достигните её, с уклоном на качество (а не лишь бы накалякать).

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