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

Откуда: Москва
Сообщений: 455
mayton
Есть описание таблички plan_production_finished_products в виде ddl?

полудух
мда, ну тут вообще не к БД претензии
если увидим DDL таблицы, думаю будем плакать всем форумом


Одна таблица используется в расчетах.
create table calc.plan_production_finished_products
(

		 row_id							INT					NOT NULL	IDENTITY(1,1)	
		,data_type						varchar(100)		NOT NULL
		,name_system					varchar(7)				NULL
		,path_file						varchar(300)			NULL
		,date_file						datetime				NULL
		,download_user					varchar(50)				NULL
		,dt_tm_insert					datetime				NULL
									
		,reason_ignore_in_calculate		VARCHAR(300)			NULL

		,sap_id							BIGINT					NULL
		,sap_id_text					as convert(varchar(24), FORMAT(sap_id, '000000000000000000000000'))
		,sap_id_original				BIGINT					NULL
		,sap_id_original_text			as convert(varchar(24), FORMAT(sap_id_original, '000000000000000000000000'))
		,sap_id_expiration_date_in_days	SMALLINT				NULL

		,stuffing_id					VARCHAR(40)				NULL
		,stuffing_id_box				VARCHAR(40)				NULL

		,position_dependent_id			INT						NULL	
		,individual_marking_id			TINYINT					NULL	
		,article_nomenclature			VARCHAR(20)				NULL	
		,article_packaging				VARCHAR(25)				NULL	
		,product_finished_id			decimal(14, 0)			NULL


		--- остатки ---
		,stock_sort_row					INT						NULL -- используется для расчетов
		,stock_warehouse_name			VARCHAR(100)			NULL	
		,stock_storage_area_name		VARCHAR(100)			NULL	
		,stock_branch_name				VARCHAR(100)			NULL
		,stock_production_date			DATETIME				NULL
		,stock_on_date					DATETIME				NULL
		,stock_expiration_date			DATETIME				NULL
		,stock_kg						dec(11,5)				NULL

		,stock_current_KOS				as case when stock_production_date >= stock_expiration_date then null  
												when stock_production_date >  stock_on_date		    then null
												when stock_expiration_date <= stock_on_date		    then 0.000000	
												when stock_production_date	= stock_on_date			then 1
												else DATEDIFF(day, stock_on_date, stock_expiration_date) * 1.0 / DATEDIFF(day, stock_production_date, stock_expiration_date) end

		,stock_KOS_in_day				as case when stock_production_date >= stock_expiration_date then null	
												when stock_production_date >  stock_on_date			then null
												else 1.0 / DATEDIFF(day, stock_production_date, stock_expiration_date) end	
													



		--- набивки ---
		,stuffing_sort_row						INT					NULL -- используется для расчетов
		,stuffing_production_name				VARCHAR(100)		NULL
		,stuffing_production_date_from			DATETIME			NULL
		,stuffing_production_date_to			DATETIME			NULL
		,stuffing_available_date				DATETIME			NULL
		,stuffing_expiration_date				DATETIME			NULL
		,stuffing_maturation					tinyint				NULL
		,stuffing_maturation_and_packaging		tinyint				NULL
		,stuffing_transit_from_production_days	tinyint				null	

		,stuffing_begin_production_date_from	DATETIME			NULL -- дата с которой можем закладывать
		,stuffing_begin_production_date_to		as stuffing_begin_production_date_from + stuffing_maturation
		,stuffing_begin_available_date			as stuffing_begin_production_date_from + stuffing_maturation_and_packaging + stuffing_transit_from_production_days

		,stuffing_kg							dec(11,5)			NULL

		,stuffing_current_KOS				as case when stuffing_production_date_to >= stuffing_expiration_date	then null  
													when stuffing_production_date_to >  stuffing_available_date		then null
													when stuffing_expiration_date	 <= stuffing_available_date		then 0.000000
													when stuffing_production_date_to  = stuffing_available_date		then 1		
													else DATEDIFF(day, stuffing_available_date, stuffing_expiration_date) * 1.0 / DATEDIFF(day, stuffing_production_date_to, stuffing_expiration_date) end

		,stuffing_KOS_in_day				as case when stuffing_production_date_to >= stuffing_expiration_date then null	
													when stuffing_production_date_to >  stuffing_available_date	 then null
													else 1.0 / DATEDIFF(day, stuffing_production_date_to, stuffing_expiration_date) end	




		-- заявки и план продаж
		,shipment_sales_channel_id		TINYINT					NULL
		,shipment_sales_channel_name	VARCHAR(25)				NULL
		,shipment_branch_id				VARCHAR(20)				NULL	
		,shipment_branch_name			VARCHAR(100)			NULL	
		,shipment_customer_id			VARCHAR(20)				NULL
		,shipment_customer_name			VARCHAR(100)			NULL

		,shipment_priority				TINYINT					NULL
		,shipment_priority_for_stuffing tinyint					NULL -- для набивок когда сортировку делаем по приоритету
		,shipment_date					DATETIME				NULL
		,shipment_min_KOS				DEC(7,6)				NULL
		,shipment_kg					dec(11,5)				NULL

		-- расчетные поля

		,stock_shipment_kg				dec(11,5)				NULL
		,stock_net_need					as case when data_type in ('ЗАЯВКИ', 'ПЛАН ПРОДАЖ') then nullif( shipment_kg - isnull(stock_shipment_kg, 0)   , 0) end

		,stuffing_marking_kg			dec(11,5)				NULL			   
		,stuffing_shipment_kg			dec(11,5)				NULL	-- кол-во которое уже отгружено из набивки включая маркировку
		,stuffing_net_need				as case when data_type in ('ЗАЯВКИ', 'ПЛАН ПРОДАЖ') then nullif(   shipment_kg - isnull(stock_shipment_kg, 0) - isnull(stuffing_shipment_kg, 0)   , 0) end

)



L.Otujktd
Focha,

Я бы попробовал все перенести в объектное представление и в linq завернуть потихоньку и что-то респараллелить/закешировать. Плюс в это во всем что можно прикрутить визуализацию и красивые диаграммы

Как понимаю если mssql то C# наверное надо попробовать.

mayton
А зачем индексы создаются и убиваются? Странная практика.

Из Ораклового опыта... я-бы их 1 раз создал как HIDDEN. И потом в запросах активировал бы когда
надо хинтами.

И еще вопрос
1) Сколько всего строк в табличке plan_production_finished_products?
2) Сколько из них реально используются в расчетах?


1) Строк 100 000 всего
2) Цикл бегает по строкам
Спасибо, что-то не подумал включать и отключать, так и сделаю


полудух
Focha
Алгоритм все считает в 2 хранимках на сервере, но мне кажется, реализация на t-sql мягко говоря это не то.

а чего нет? Чем ближе к данным, тем лучше.
считает "всё"
считает быстро
считает правильно
работает - не тронь (с)

если тащить это куда-то ИЗ базы, значит уже лишнюю работу делать
быстрее будет, только если алгоритмы говно, тогда конечно можно взять C++ и заюзать евойные алгоритмы
это будет оптимально.
Focha
А вы делали большие и сложные расчеты

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


А как же совершенствовать свое творение?
На момент когда разрабатываешь с нуля кажется расчет сложный, а когда завершаешь разработку, то понимаешь, что тут всего 10 строк кода.
CLR работает внутри базы, так что думаю попробовать перенести расчет на C# CLR, но это не значит, что я отключу хранимки. Хочу попробовать


полудух
Focha
данный кусок работает ~10 секунд, а все 2 минуты. я думаю где-то есть истина, что такие расчеты "легче" разработать на чем-то другом.

это от запросов и алгоритма зависит
перетащить данные в C++ будет ещё дольше
но скорость расчётов останется ~такой же, если алгоритм не изменить

Да, зависит, вот и думаю, что на C# можно придумать другой алгоритм
5 сен 19, 08:57    [21964191]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
Focha
Member

Откуда: Москва
Сообщений: 455
monstrU
я бы тут рассматривал выбор - бизнес логику держать в БД или в приложении.
сейчас ты выбрал вариант 2.
у обеих есть плюсы и минусы.
по бд
плюсы - в теории сравнительно быстро работает (на практике как угодно), просто подменить
минусы- трудозатратно в разработке и сопровождении, юнит тесты в архитектуре не предусмотрены

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

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

у тебя вот написаны 2 процедуры - как ты будешь уверен через 3 месяца, что они поддерживают тот же функционал, что и сегодня без тестов? никак.

обычно заводят логический слой - типа классы OrderService, в котором реализовывают методы, занимающиеся формированием заказа, как у тебя. в БД такие классы не лезут - для этого отдельный слой заводят.

в общем срач не первый на эту темы.

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


Почему я выбрал 2, если бизнес логику держу в БД. Очень интересный ответ, спасибо
5 сен 19, 09:02    [21964198]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
ViPRos
Member

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

оставь как есть
5 сен 19, 11:21    [21964343]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
индексы забыли.
Focha
А как же совершенствовать свое творение?

так совершенствовать надо знания БД и алгоритмику
вот так нельзя делать вообще никогда:
where data_type in ('заявки', 'план продаж') 
	and reason_ignore_in_calculate is null;

"заявки" и "план продаж" это справочники и искать надо, соответственно, по ID

автор
Например задача, мне нужно сделать график отгрузки, с учетом графика работы и вместимости машин. Алгоритм должен заполнить машину на 99%-100%, кол-во машин ограничено, заказ нельзя разделять (в 1 машину можно больше 1 заказа, но нельзя 0.5 заказа). Задача стандартная в логистике.

не выглядит как неподъёмная для plsql задача
но если прям никак, то сделайте свой SELECT и посчитайте, где удобно
хоть посмотрите, а оно вам вообще поможет или всё таки дело в алгоритмах
5 сен 19, 11:50    [21964380]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
Focha
Member

Откуда: Москва
Сообщений: 455
ViPRos
Focha,
оставь как есть
а я не собирался менять, я думаю о других инструментах

полудух
индексы забыли.
так совершенствовать надо знания БД и алгоритмику
вот так нельзя делать вообще никогда:
"заявки" и "план продаж" это справочники и искать надо, соответственно, по ID
не выглядит как неподъёмная для plsql задача
но если прям никак, то сделайте свой SELECT и посчитайте, где удобно
хоть посмотрите, а оно вам вообще поможет или всё таки дело в алгоритмах

индексы создаются позже, когда таблица данными заполниться, по совету выше переделал, на включение и выключение индексы.
Спасибо за совет "так совершенствовать надо знания БД и алгоритмику" и еще CLR совершенствовать буду
5 сен 19, 12:25    [21964413]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Focha
1) Строк 100 000 всего
2) Цикл бегает по строкам
Спасибо, что-то не подумал включать и отключать, так и сделаю

Смотри. Эффективность альтернативного решения должна базироваться на том что мы.

1) Из таблицы в 100 000 строк выбираем выборку X строк
where data_type in ('заявки', 'план продаж') 
	and reason_ignore_in_calculate is null;


и сохраняем их в коллекции CLR/C++/Java/Python e.t.c.

2) Выполняем процессинг данных в коллекциях в точности по тому-же алгоритму который реализован в T-SQL
+

Есть ли какое-то международное название у этого алгоритма? Что это? Транспортная задача? Transport Problem?
Combinatorial optimization? Если мы найдем ее каноническую формулировку то - будет и коробочное решение.

3) Сохраняем результат в #log_change

Недостатки.

Мы должны гарантировать что трансфер X строк в коллекции будет быстрее чем 2 минуты.
Если это не так - то альтернативное решение бесполезно.

При этом мы должны быстро сбрасывать результаты в лог изменений. Если они будут медленнее чем 2 минуты
то альтернатива тоже не подходит.

Объем коллекций (хеш-таблиц и деревьев и графов) в памяти не должен превышать доступную память машины
где идет вычисление. Выполнять это напрямую на сервере также опасно. Память сервера обычно занята задачами
БД и как-то забирать у нее ресурсы - нехорошо. Теряется контроль над ситуацией. ДБА тоже поставлен в сложное
положение.
5 сен 19, 14:59    [21964639]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
L.Otujktd
Member

Откуда:
Сообщений: 81
Focha,
Я так понимаю задачка у Вас на перспективу, тк входные данные одни, а вариантов обработки потенциально много. Те вопрос в том, как разработать систему, которую можно былобы гибко адаптировать под другие алгоритмы используя какие-то уже готовые блоки. на выходе вообще получается подобие nosql , судя по общей картине.
5 сен 19, 22:08    [21964953]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Focha
индексы создаются позже, когда таблица данными заполниться, по совету выше переделал, на включение и выключение индексы.

я говорю - DDL без индексов это просто портянка
"создаются позже" это зачем/почему?
5 сен 19, 22:28    [21964970]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
Focha
Member

Откуда: Москва
Сообщений: 455
mayton
Смотри. Эффективность альтернативного решения должна базироваться на том что мы.
1) Из таблицы в 100 000 строк выбираем выборку X строк
и сохраняем их в коллекции CLR/C++/Java/Python e.t.c.
2) Выполняем процессинг данных в коллекциях в точности по тому-же алгоритму который реализован в T-SQL
3) Сохраняем результат в #log_change
Недостатки.
Мы должны гарантировать что трансфер X строк в коллекции будет быстрее чем 2 минуты.
Если это не так - то альтернативное решение бесполезно.
При этом мы должны быстро сбрасывать результаты в лог изменений. Если они будут медленнее чем 2 минуты
то альтернатива тоже не подходит.
Объем коллекций (хеш-таблиц и деревьев и графов) в памяти не должен превышать доступную память машины
где идет вычисление. Выполнять это напрямую на сервере также опасно. Память сервера обычно занята задачами
БД и как-то забирать у нее ресурсы - нехорошо. Теряется контроль над ситуацией. ДБА тоже поставлен в сложное
положение.
Сервер используется как раз для расчетов, не для учета каких-то данных.
Ваше утверждение больше говорит о том как посчитать, я понимаю, что любой алгоритм можно написать на CLR/C++/Java/Python e.t.c. , пока из всех ответом мне больше нравиться перенести на C# и ООП, не факт, что будет быстрее, но я получу внутренне спокойствие, что делаю все верно. Python/R тоже вариант
L.Otujktd
Focha,
Я так понимаю задачка у Вас на перспективу, тк входные данные одни, а вариантов обработки потенциально много. Те вопрос в том, как разработать систему, которую можно былобы гибко адаптировать под другие алгоритмы используя какие-то уже готовые блоки. на выходе вообще получается подобие nosql , судя по общей картине.
Спасибо вам, вы мне помогаете более точно определить, что я хочу, только не разработать, а какой инструмент выбрать.
Может сможете посоветовать, что использовать?
полудух
Focha
индексы создаются позже, когда таблица данными заполниться, по совету выше переделал, на включение и выключение индексы.

я говорю - DDL без индексов это просто портянка
"создаются позже" это зачем/почему?
Вы можете забыть про mssql? представьте у меня есть задача, данные хранятся в таблице и мне нужно произвести расчет без t-sql
6 сен 19, 09:11    [21965075]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
monstrU
Member

Откуда: Москва
Сообщений: 1164
Focha
Вы можете забыть про mssql? представьте у меня есть задача, данные хранятся в таблице и мне нужно произвести расчет без t-sql


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

и все равно, где у тебя хранятся данные -в таблице, их отдает веб сервис, конструируешь их в оператовной памяти.
так ты плавно дойдешь до формирования логического слоя БЛ в приложении. и при получении советов - написать clr в БД будешь думать - нафиг мне внедрять C# в бд если эта логика и так в приложении сидит
6 сен 19, 09:32    [21965091]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Focha
Вы можете забыть про mssql? представьте у меня есть задача, данные хранятся в таблице и мне нужно произвести расчет без t-sql

да вы всё никак в толк не возьмёте, что вам нужно будет перетаскивать данные из БД в
Focha
CLR/C++/Java/Python e.t.c.

а делать вам это через WHERE, где те самые индексы и участвуют
у вас и сейчас алгоритмы тормозят частично из-за индексов
но потом у вас всё будет тормозить ещё и потому, что 100000 строк надо перетащить в другое место Картинка с другого сайта.
6 сен 19, 10:10    [21965123]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
ИВП
Member

Откуда:
Сообщений: 238
Как-то задача нечетко сформулирована.
Ограничения есть, а целевой функции нет.
Просто распихать груз по транспортным средствам? Можно по-разному, а что критерием является?
6 сен 19, 10:43    [21965159]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
Focha
Member

Откуда: Москва
Сообщений: 455
Тема закрыта, буду копать в сторону алгоритмов и C#
6 сен 19, 11:27    [21965192]     Ответить | Цитировать Сообщить модератору
 Re: На чем создать расчет, поделитесь опытом  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Есть готовый код который работает. Разве мы не можем получить из него алгоритм?

Это называется реверс-инжинеринг.

Конешно лучше не решать данную задачу таким образом а генерализировать ее.
Найти обобщённый подход. И решить через него. Канонически.
6 сен 19, 14:00    [21965356]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Программирование Ответить