Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 "Большая хранимая" t-sql процедура  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Приветствую всех.
ОС: Windows 2008 R2
Сервер БД: SQL Server 2008 R2

В одной моей разработке я перенес большую часть работы с данными на сторону SQL: хранимки, udf'ки и т.д.
Раньше большая часть обработки данных была на внешних приложениях, написанных .NET.
Теперь почти 90%ов работы на стороне БД.

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

В основном код заключается в несложном парсинге строк (LEFT, SUBSTRING, CHARINDEX) и т.д., длина строк не более 300 символов.
И количество этих строк тоже не много. Есть одна входная строка, которая делится на подстроки и идет обработка.
И еще, частое обращение к данным в базе (поиск, контроль значений и несколько update'ов), поэтому решил перенести эти обработки данных в T-SQL хранимку. До этого эти логические обработки были в .NET CLR хранимке.
В нете про это написано что если сложных расчетов нету, или обращений к OLE объектам или к внешним файлам, T-SQL хранимки лучше чем .NET CLR хранимки.

Хотел выслушать Ваши мнения по этому вопросу. Не будет ли влиять такое количество строк хранимки на саму работу?

Спасибо за внимание.
18 мар 12, 14:46    [12268851]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31991
orunbek
Теперь почти 90%ов работы на стороне БД.

Поэтому код одной из хранимок стал "большим", т.е. где-то чуть меньше 3000 строк.
Причинно-следственная связь неясна.

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

orunbek
И еще, частое обращение к данным в базе (поиск, контроль значений и несколько update'ов), поэтому решил перенести эти обработки данных в T-SQL хранимку. До этого эти логические обработки были в .NET CLR хранимке.
В нете про это написано что если сложных расчетов нету, или обращений к OLE объектам или к внешним файлам, T-SQL хранимки лучше чем .NET CLR хранимки.
Да в общем правильно. Сиквел не очень хорошо подходжит для парсинга строк, но зато поддерживать базу будет проще. Если объёмы небольшие, то нормальное решение.
18 мар 12, 14:56    [12268882]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
alexeyvg
orunbek
Теперь почти 90%ов работы на стороне БД.

Поэтому код одной из хранимок стал "большим", т.е. где-то чуть меньше 3000 строк.
Причинно-следственная связь неясна.

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

orunbek
И еще, частое обращение к данным в базе (поиск, контроль значений и несколько update'ов), поэтому решил перенести эти обработки данных в T-SQL хранимку. До этого эти логические обработки были в .NET CLR хранимке.
В нете про это написано что если сложных расчетов нету, или обращений к OLE объектам или к внешним файлам, T-SQL хранимки лучше чем .NET CLR хранимки.
Да в общем правильно. Сиквел не очень хорошо подходжит для парсинга строк, но зато поддерживать базу будет проще. Если объёмы небольшие, то нормальное решение.


Логика, грубо говоря, такова
Управление некой системой через короткие команды
"1" - получение баланса
"1#ddmmyy" - получение баланса на дату ddmmyy
"2#clientid#sum" - создание оплаты на клиента clientid на сумму sum
"3#clientid#ddmmyy" - получение баланса клиента clientid на дату ddmmyy

что-то вроде этого, думаю обработки таких данных в T-SQL потребует не так уже много процессорного времени
и по сравнению с парсингом в .NET CLR хранимке поэффективнее будет, с перидической выборкой данных
18 мар 12, 15:45    [12269035]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek
Логика, грубо говоря, такова
Управление некой системой через короткие команды
"1" - получение баланса
"1#ddmmyy" - получение баланса на дату ddmmyy
"2#clientid#sum" - создание оплаты на клиента clientid на сумму sum
"3#clientid#ddmmyy" - получение баланса клиента clientid на дату ddmmyy
Это не логика системы это логика интерфейса. Переносить логику интерфайса в скуль была ошибкой.

Нужно было сделать соответствующие функции (процедуры) на SQL-е. А клиет должен был их вызвать согласно интерфейсу сервера.
Никаких ddmmyy - это маразмы, только явные типы данных (DateTime на клиенте, и Date на сервере). Пусть эти преобрахования будут на уровне контроллера (на клиенте) [согласно парадигме Модель-Отображение-Контроллер].

Блин, из крайности в крайность.
18 мар 12, 18:04    [12269553]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior
orunbek
Логика, грубо говоря, такова
Управление некой системой через короткие команды
"1" - получение баланса
"1#ddmmyy" - получение баланса на дату ddmmyy
"2#clientid#sum" - создание оплаты на клиента clientid на сумму sum
"3#clientid#ddmmyy" - получение баланса клиента clientid на дату ddmmyy
Это не логика системы это логика интерфейса. Переносить логику интерфайса в скуль была ошибкой.

Нужно было сделать соответствующие функции (процедуры) на SQL-е. А клиет должен был их вызвать согласно интерфейсу сервера.
Никаких ddmmyy - это маразмы, только явные типы данных (DateTime на клиенте, и Date на сервере). Пусть эти преобрахования будут на уровне контроллера (на клиенте) [согласно парадигме Модель-Отображение-Контроллер].

Блин, из крайности в крайность.


клиента нету, эти команды передаются через смс
количество этих смс, одновременно поступающих может быть больше 20ти, так как несколько SMS-каналов
система очереди реализована через Service Broker, и логическая обработка этих сообщений раньше была через .NET CLR хранимку
сейчас перенес в T-SQL хранимку, так как в основном идет несложный парсинг текста

программы принимающие эти сообщения сразу скидывают в таблицу входящих сообщений, а в нем триггер
передает идентификатор новой записи через сообщение Service Broker'а
18 мар 12, 20:14    [12270147]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
orunbek,

Все равно вам бы не помешало на каждую команду иметь по процедуре с вменяемыми параметрами и одну управляющую процедуру, которая будет их вызывать. Одна большая процедура на 3К строк -- это ад для сопровождения.
18 мар 12, 20:31    [12270217]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
если это вопрос
Guest
orunbek
Не будет ли влиять такое количество строк хранимки на саму работу?

количество строк хранимки влияет на время ее компиляции
и косвенно может влиять на количество перекомпиляций.
для хранимок вызываемых пять раз в сутки это не имеет никакого значения.
18 мар 12, 23:01    [12270740]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
если это вопрос
Guest
invm
Одна большая процедура на 3К строк -- это ад для сопровождения.

это про 3К строк написанных уродом.
нормальные 3К в одной процедуре ничем не отличаются от 3х процедур по 1К.
если эти строки собраны в одном месте со смыслом, то разнесение их по отдельным процам может и ухудшить.
вот 3К процедур - это уже непросто. а одна на 3К строк - это пара рефакторингов с комментарингами.
18 мар 12, 23:05    [12270753]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
если это вопрос
invm
Одна большая процедура на 3К строк -- это ад для сопровождения.

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

Процедура на 3К строк нормальной быть не может. Ибо можно хоть укоментироваться и обрефакториться, все равно при ее прочтении, в конце уже не будешь помнить, что у нее в начале. Такой подход годится только в исключительных случаях.
18 мар 12, 23:16    [12270799]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
если это вопрос
Guest
invm
если это вопрос
пропущено...

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

Процедура на 3К строк нормальной быть не может. Ибо можно хоть укоментироваться и обрефакториться, все равно при ее прочтении, в конце уже не будешь помнить, что у нее в начале. Такой подход годится только в исключительных случаях.

все относительно. для некоторых систем и 3к - аномалия.
для некоторых вполне норма и далеко не предел. укоментировываться не нужно, это бред, достаточно блоки выделить.
для выделения отдельной процы ей как минимум отдельное название придумать нужно.
бредовые недопроцедуры сложно назвать подвигом декомпозиции.
три тысячи строк это пшик.
19 мар 12, 00:38    [12271043]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
kDnZP
Member [заблокирован]

Откуда: ★[msg=16399436]★[msg=20850760]
Сообщений: 11289
invm
Процедура на 3К строк нормальной быть не может. Ибо можно хоть укоментироваться и обрефакториться, все равно при ее прочтении, в конце уже не будешь помнить, что у нее в начале. Такой подход годится только в исключительных случаях.

Бред. Это вы запросы по 15К строк не писали. 3К на процедуру - это даже разогнаться в написании не получится... Копеечки.
19 мар 12, 01:07    [12271080]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
kDnZP
invm
Процедура на 3К строк нормальной быть не может. Ибо можно хоть укоментироваться и обрефакториться, все равно при ее прочтении, в конце уже не будешь помнить, что у нее в начале. Такой подход годится только в исключительных случаях.

Бред. Это вы запросы по 15К строк не писали. 3К на процедуру - это даже разогнаться в написании не получится... Копеечки.
У нас есть 17к. Но ни я, ни тестеры не довольны ее наличием.
19 мар 12, 01:13    [12271087]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
kDnZP
Member [заблокирован]

Откуда: ★[msg=16399436]★[msg=20850760]
Сообщений: 11289
Гавриленко Сергей Алексеевич, угу, а я недоволен той хренью которая летает между сервером приложений и сервером баз данных. Особенно когда приходят ко мне консультанты и говорят: оптимизируй-ка запросик для отчета, вида:
select top 1 ... from ... where ...

который мульен раз туда-сюда между ними гоняется, ибо отак написано было любителями ORM. И как тут оптимизировать? Тут переписывать надобно.

------------
Запрос на 15к, о котором я говорил - это тоже один из отчетов, в котором 2 иерархии и 1 история. Но как по мне он вполне читаемый, т.к. разносил его логическими блоками в CTE, т.е. по совести то же самое можно было через вьюхи делать, если бы возникла такая необходимость.
19 мар 12, 01:28    [12271096]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
99.9 % больших размеров кода, включая данный случай, из-за неправильной архитектуры или процедурномыслия.

Почему может быть 3 малых больше одного: Если 1 запускается в 100500 раз чаще других, то в оперативе будет хранится только его план. Остальные будут практически сразу же вытеснены.

Параметризованные объекты были как раз и сделаны как внешний интерфейс. Процедуры только для этого и сделаны.

Для меня и 500 строк уже многовато.
19 мар 12, 02:51    [12271143]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
kDnZP
invm
Процедура на 3К строк нормальной быть не может. Ибо можно хоть укоментироваться и обрефакториться, все равно при ее прочтении, в конце уже не будешь помнить, что у нее в начале. Такой подход годится только в исключительных случаях.

Бред. Это вы запросы по 15К строк не писали. 3К на процедуру - это даже разогнаться в написании не получится... Копеечки.
Не писал и не собираюсь. Вменяемый разработчик такое руками не напишет, за исключением редких специфических ситуаций, когда это действительно необходимо. Так что, в основном, такие конструкции результат жизнедеятельность ОРМовских бредогенераторов.
19 мар 12, 08:07    [12271284]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
kDnZP
Member [заблокирован]

Откуда: ★[msg=16399436]★[msg=20850760]
Сообщений: 11289
invm
Вменяемый разработчик такое руками не напишет

Ну что я могу на это сказать? Значит я невменяемый разработчик, потому как запрос писал руками. И он не в единичном экземпляре. *

* Какого монстра при заданных условиях (2 иерархии + 1 история + логика) создаст ORM я вообще боюсь представить, но так как набор кирпичиков кодогенерации ограничен, то это будет:
1. Хорошо, если не более чем в 100 раз медленнее
2. Хорошо, если хотябы на 10% понятнее

** Да, на счет архитектуры и т.д. - это не ко мне, это к Microsoft, т.к. это их ERP/CRM .
19 мар 12, 09:38    [12271520]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
kDnZP, ну я же писал -- "за исключением редких специфических ситуаций, когда это действительно необходимо".
И как вам нравится сопровождать такого монстра? Речь-то шла именно о сопровождении.
19 мар 12, 09:47    [12271552]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
kDnZP
Member [заблокирован]

Откуда: ★[msg=16399436]★[msg=20850760]
Сообщений: 11289
invm
И как вам нравится сопровождать такого монстра? Речь-то шла именно о сопровождении.

Да без проблем вобщем-то...
В самом внизу пишу нечто вида:
select * from cte1 -- cte2 -- cte3

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

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

* Ну да ладно, гляжу на меня тут набросились с общественным порицанием, так что переубеждать не буду.

+
Просто рядом сидит разработчик, который при словах: "Поправь свой отчет, сделанный по всем канонам ORM начинает впадать в уныние", ибо это день работы в лучшем случае, т.к. 2 часа ожидания на каждое построение отчета это слегка напрягает... Про тестирование - вообще молчу.

При этом я прикинул (методом прикидочного тестирования), что переписав на SQL можно снизить время формирования с 2 часов до 1 минуты, вот если созреют наши доблестные постановщики - перепишу))). Будет еще один монстрик, но без тормозов и как по мне - лучше понимаемый и поддерживаемый.
19 мар 12, 10:03    [12271627]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
посмотрим, "жизнь" покажет:
если t-sql хранимка в 3к строк будет более эффективна, оставлю этот вариант
но если будет похуже чем раньше, когда использовал .NET CLR SP, рассмотрю варианты оптимизации, может обратно верну .NET CLR хранимку
но, имхо конечно, если не сложный парсинг строк и частое обращение к базе, и сам код не такой уж сложный, разделенный на блоки (из-за этого тоже "распухшая" хранимка)
+ Например (отрывок из "шедевра" ) :

	END ELSE IF ISNUMERIC(@Temp1)=0 BEGIN
		SET @IncQueryStatus_ID=4
		SET @StatusDescription=N'Ошибка в конечной дате'
		SET @result=-1000
		
		IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
			SET @CreateOut=1
			SET @OutMessageCoding=8
			SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
		END
	
	END ELSE BEGIN
		BEGIN TRY
			SET @TempNum=CAST(@Temp1 AS bigint)
			IF (@TempNum<=0) OR (@TempNum>31) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в начальной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE IF @TempNum>DAY(DATEADD(ms,-5,DATEADD(mm,DATEDIFF(m,0,@ServerD)+1,0))) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в конечной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE BEGIN
				SET @DT2=CAST(CONVERT(varchar,YEAR(@ServerD))+RIGHT('0'+CONVERT(varchar(2),MONTH(@ServerD)),2)+RIGHT('0'+CONVERT(varchar(2),@TempNum),2) AS date)
				
				IF @DT2>@ServerD BEGIN
					SET @IncQueryStatus_ID=4
					SET @StatusDescription=N'Ошибка в конечной дате'
					SET @result=-1000
					
					IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
						SET @CreateOut=1
						SET @OutMessageCoding=8
						SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
					END
				END
			END
		END TRY
		BEGIN CATCH
			SET @IncQueryStatus_ID=4
			SET @StatusDescription=N'Ошибка в конечной дате'
			SET @result=-1000
			
			IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
				SET @CreateOut=1
				SET @OutMessageCoding=8
				SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
			END
		END CATCH
	END
END
	END ELSE IF ISNUMERIC(@Temp1)=0 BEGIN
		SET @IncQueryStatus_ID=4
		SET @StatusDescription=N'Ошибка в конечной дате'
		SET @result=-1000
		
		IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
			SET @CreateOut=1
			SET @OutMessageCoding=8
			SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
		END
	
	END ELSE BEGIN
		BEGIN TRY
			SET @TempNum=CAST(@Temp1 AS bigint)
			IF (@TempNum<=0) OR (@TempNum>31) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в начальной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE IF @TempNum>DAY(DATEADD(ms,-5,DATEADD(mm,DATEDIFF(m,0,@ServerD)+1,0))) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в конечной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE BEGIN
				SET @DT2=CAST(CONVERT(varchar,YEAR(@ServerD))+RIGHT('0'+CONVERT(varchar(2),MONTH(@ServerD)),2)+RIGHT('0'+CONVERT(varchar(2),@TempNum),2) AS date)
				
				IF @DT2>@ServerD BEGIN
					SET @IncQueryStatus_ID=4
					SET @StatusDescription=N'Ошибка в конечной дате'
					SET @result=-1000
					
					IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
						SET @CreateOut=1
						SET @OutMessageCoding=8
						SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
					END
				END
			END
		END TRY
		BEGIN CATCH
			SET @IncQueryStatus_ID=4
			SET @StatusDescription=N'Ошибка в конечной дате'
			SET @result=-1000
			
			IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
				SET @CreateOut=1
				SET @OutMessageCoding=8
				SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
			END
		END CATCH
	END



то T-SQL хранимка по лучше должна быть чем .NET CLR хранимка
19 мар 12, 13:08    [12273075]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
и где тут работа с данными
Guest
orunbek
я перенес большую часть работы с данными

orunbek
+
+ Например (отрывок из "шедевра" ) :

	END ELSE IF ISNUMERIC(@Temp1)=0 BEGIN
		SET @IncQueryStatus_ID=4
		SET @StatusDescription=N'Ошибка в конечной дате'
		SET @result=-1000
		
		IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
			SET @CreateOut=1
			SET @OutMessageCoding=8
			SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
		END
	
	END ELSE BEGIN
		BEGIN TRY
			SET @TempNum=CAST(@Temp1 AS bigint)
			IF (@TempNum<=0) OR (@TempNum>31) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в начальной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE IF @TempNum>DAY(DATEADD(ms,-5,DATEADD(mm,DATEDIFF(m,0,@ServerD)+1,0))) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в конечной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE BEGIN
				SET @DT2=CAST(CONVERT(varchar,YEAR(@ServerD))+RIGHT('0'+CONVERT(varchar(2),MONTH(@ServerD)),2)+RIGHT('0'+CONVERT(varchar(2),@TempNum),2) AS date)
				
				IF @DT2>@ServerD BEGIN
					SET @IncQueryStatus_ID=4
					SET @StatusDescription=N'Ошибка в конечной дате'
					SET @result=-1000
					
					IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
						SET @CreateOut=1
						SET @OutMessageCoding=8
						SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
					END
				END
			END
		END TRY
		BEGIN CATCH
			SET @IncQueryStatus_ID=4
			SET @StatusDescription=N'Ошибка в конечной дате'
			SET @result=-1000
			
			IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
				SET @CreateOut=1
				SET @OutMessageCoding=8
				SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
			END
		END CATCH
	END
END
	END ELSE IF ISNUMERIC(@Temp1)=0 BEGIN
		SET @IncQueryStatus_ID=4
		SET @StatusDescription=N'Ошибка в конечной дате'
		SET @result=-1000
		
		IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
			SET @CreateOut=1
			SET @OutMessageCoding=8
			SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
		END
	
	END ELSE BEGIN
		BEGIN TRY
			SET @TempNum=CAST(@Temp1 AS bigint)
			IF (@TempNum<=0) OR (@TempNum>31) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в начальной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE IF @TempNum>DAY(DATEADD(ms,-5,DATEADD(mm,DATEDIFF(m,0,@ServerD)+1,0))) BEGIN
				SET @IncQueryStatus_ID=4
				SET @StatusDescription=N'Ошибка в конечной дате'
				SET @result=-1000
				
				IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
					SET @CreateOut=1
					SET @OutMessageCoding=8
					SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
				END
			END ELSE BEGIN
				SET @DT2=CAST(CONVERT(varchar,YEAR(@ServerD))+RIGHT('0'+CONVERT(varchar(2),MONTH(@ServerD)),2)+RIGHT('0'+CONVERT(varchar(2),@TempNum),2) AS date)
				
				IF @DT2>@ServerD BEGIN
					SET @IncQueryStatus_ID=4
					SET @StatusDescription=N'Ошибка в конечной дате'
					SET @result=-1000
					
					IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
						SET @CreateOut=1
						SET @OutMessageCoding=8
						SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
					END
				END
			END
		END TRY
		BEGIN CATCH
			SET @IncQueryStatus_ID=4
			SET @StatusDescription=N'Ошибка в конечной дате'
			SET @result=-1000
			
			IF (@OutChannel_ID<>-1) AND (@OutQueryStatus=1) BEGIN
				SET @CreateOut=1
				SET @OutMessageCoding=8
				SET @OutMessage=N'Ошибка в конечной дате. Запрос: '+@Message
			END
		END CATCH
	END



то T-SQL хранимка по лучше должна быть чем .NET CLR хранимка

и где тут работа с данными?
это не вопрос CLR vs SP, это вопрос "нахрена все это крутится на сервере БД"?
у вас кто угодно может дернуть процедуру с какими угодно параметрами?
может в той обертке которая их дергает и выполнять проверки на корректность параметров?
может текст клиентской ошибки соответствующий коду возврата оставить клиенту?
и нахрена эта тонна копипаста? не удивлюсь если весь приведенный код можно перевести в один кейс который займет строк двадцать.
при все этой тонне проверок начальной и конечной даты вы dateadd+datediff в try-catch заворачиваете?
19 мар 12, 16:38    [12275175]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3755
orunbek
Логика, грубо говоря, такова
Управление некой системой через короткие команды
"1" - получение баланса
"1#ddmmyy" - получение баланса на дату ddmmyy
"2#clientid#sum" - создание оплаты на клиента clientid на сумму sum
"3#clientid#ddmmyy" - получение баланса клиента clientid на дату ddmmyy

Сделать процедуру с тремя параметрами: команда, дата, клиент
Всю разборку строки делать в клиенте и ошибки там же генерить - а процедуру дергать уже потом !!
19 мар 12, 19:34    [12276701]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
12270147
Ща опять прибежит толпа и TC снова не увидит этот пост. :)

orunbek, бывает так что прибегают гуру и говорят по связанной теме, но не касающиеся первоначальной задачи.
19 мар 12, 21:28    [12277218]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
kDnZP
invm
Вменяемый разработчик такое руками не напишет

Ну что я могу на это сказать? Значит я невменяемый разработчик, потому как запрос писал руками. И он не в единичном экземпляре. *

* Какого монстра при заданных условиях (2 иерархии + 1 история + логика) создаст ORM я вообще боюсь представить, но так как набор кирпичиков кодогенерации ограничен, то это будет:
1. Хорошо, если не более чем в 100 раз медленнее
2. Хорошо, если хотябы на 10% понятнее

** Да, на счет архитектуры и т.д. - это не ко мне, это к Microsoft, т.к. это их ERP/CRM .
ТРИЗ говорит: Если система очень большая, сложня и неподъёмная то ... нужно её разбить на части (как одно из решений).

Ещё можно сконструировать пред-действие.

А может быть нужно просто коренным образом изменить логику процедуры и она будет занимать всего сотню строк?
19 мар 12, 22:59    [12277759]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
SandalTree, троллингом что ли занимаетесь?
orunbek
Логика такова: Управление системой через команды:
командадействие
1получение баланса
1#ddmmyyполучение баланса на дату ddmmyy
2#clientid#sumсоздание оплаты на клиента clientid на сумму sum
3#clientid#ddmmyyполучение баланса клиента clientid на дату ddmmyy
Болтология на парсинге строки?
Уже писал это не логика, это интерфейс. Его место - клиент.
Тем более на .Net занимает 3 строки.
А на скуле 2 задачи:
- баланс
- оплата

Всё! Нет тут бла-бла и моря кода.
19 мар 12, 23:49    [12278038]     Ответить | Цитировать Сообщить модератору
 Re: "Большая хранимая" t-sql процедура  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Mnior
SandalTree, троллингом что ли занимаетесь?
orunbek
Логика такова: Управление системой через команды:
командадействие
1получение баланса
1#ddmmyyполучение баланса на дату ddmmyy
2#clientid#sumсоздание оплаты на клиента clientid на сумму sum
3#clientid#ddmmyyполучение баланса клиента clientid на дату ddmmyy
Болтология на парсинге строки?
Уже писал это не логика, это интерфейс. Его место - клиент.
Тем более на .Net занимает 3 строки.
А на скуле 2 задачи:
- баланс
- оплата

Всё! Нет тут бла-бла и моря кода.
А что это вы так?
Как я понял на "клиенте" парсинг делать нельзя, значит нужно решать задачу в процедуре.

Процедуру МОЖНО разбить на отдельные элементы или под-задачи. Будете спорить?

Иногда даже можно завернуть всё в цикл.
==============================================================

Если-бы у меня возникла похожая задача, то я-бы попытался вынести собственно парсинг в другую процедуру.
Скажем задаём ей временные параметры, а она нам возвращает датасет с отпарсеными значениями, которые мы вставляем во временную таблицу и уже оперируем с ней.
19 мар 12, 23:57    [12278085]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить