Как една stored procedure да работи постоянно ?

helena 2 3 4 5 1 · 4 април 2012

Здравейте! Може би въпросът ми ще ви се стори много глупав, НО не мога да хвана идеята просото ... Имам едно приложение (на asp.net mvc) свързано с база данни (MSSQL Server) и трябва да направя така ,че една stored procedure да работи постоянно и когато се случи дадената операция (от stored procedure) да праща известия на asp.net MVC - то ... ?! И си нямам идея как се случва това "нещо" ... Ще ви бъда благодарна ,ако ми обясните концепцията и идеята : -) Благодаря предварително !!!

**darkterminal** · 4 април 2012

1. Затваряш я да се извиква през определен интервал от време от Job сървъра (SQL Agent). 2. Затваряш я да се извиква през определен интервал от време от специално написан от теб Windows Service 3. Затваряш я да се извиква през определен интервал от време от специално написан от теб AppFabric апликейшън, който рънка в същия Web Site Последния вариант е най-труден за изпълнение, но е най-чист!

helena 2 3 4 5 1 · 4 април 2012

Този интервал от време може ли да бъде постоянно (т.е. системата работи) ?! Или това си го казвам аз в Windows Service ? Малко не ми е ясно и още нещо : Когато напиша Windows Service и му кажа да я оставя да работи постоянно в самия Windows Service ли трябва да направя връзката между SQL Server и asp.net mvc приложението (за да се показва дадено View - известията от резултатът на stored procedure от SQL Server )? Благодаря МНОГО ! : -)

**capnemo** · 4 април 2012

Този интервал от време може ли да бъде постоянно (т.е. системата работи) ?!
Или това си го казвам аз в Windows Service ?

Малко не ми е ясно и още нещо :
Когато напиша Windows Service и му кажа да я оставя да работи постоянно
в самия Windows Service ли трябва да направя връзката между SQL Server и asp.net mvc приложението
(за да се показва дадено View - известията от резултатът на stored procedure от SQL Server )?

Благодаря МНОГО ! : -)

Този сървис може да я извиква през определено време. Което се разминава с моето понятие за непрекъснато. По-добре кажете крайната идея а не това, което мислите че е решение

helena 2 3 4 5 1 · 4 април 2012

Написала съм една процедура ; да взима дании от дадена таблица само

когато настъпи определен интервалът от време от часа на сървъра и

когато настъпи този интервал от време да праща на mvc - то известие ...

Ето и самата процедура :

Create procedure NotifyController
As
BEGIN
	Declare
		   @Result	              bit,
		   @CountRemaining  int,
		   @CountExpired	   int,
		   @CarID				   int,
		   @VAS					 int,
		   @ParkingID		    int,
		   @DateToArrive       date,
		   @TimeToArrive	   time(0)
		  
 
----SMS за блокиране - известие само на контролните органи : да провери дали съответната кола е още на   --паркинга : )
   Select *
   Into   TableForExpiredTime
   From   Cars
   Where  TimeToStay = convert(time,dateadd(mi,-5, getdate()))
	  and DateToArrive = convert(date,getdate())
	
   Set @CountExpired =
   (
	 Select Count(*) From  TableForExpiredTime
	)
   If (@CountExpired is NOT null)
   Begin
	   --da mu svet4e lampi4kata ,za da vidi koi koli !(true)
	   Set @Result = 1
  
      While @CountExpired > 0
      Begin
  
      Set @CarID =
      (
       Select max(CarID)
       From   TableForExpiredTime
      )
	  
      --fill in SMStable
      Set @DateToArrive =
      (
        Select DateToArrive
        From   TableForExpiredTime
        Where  CarID = @CarID
	  )
	  
	 Set @TimeToArrive =
	 (
        Select TimeToArrive
	    From   TableForExpiredTime
        Where  CarID = @CarID
	  )
	  
	 Set @ParkingID =
	 (
	    Select ParkingID
	    From   Cars
	    Where  CarID = @CarID
	 )
	  
	  
	 Set @VAS =
	 (
       Select VAS
	   From   Parkings
       Where  ParkingID = @ParkingID
	 )
	  
	
	 --delete this row in the table
	 Delete FROM TableForExpiredTime
	 Where  CarID = @CarID
	
	 Set @CountExpired = @CountExpired -1
	   End
  
   End
   if exists(Select *
			 From   SMS ..sysobjects
			 Where  name = 'TableForExpiredTime')
			 drop table TableForExpiredTime
END
Go

**capnemo** · 4 април 2012

значи не трябва да работи постоянно, а в определен момент. в такъв случай най-простото според мен решение е да настроите schedule на базата да пуска процедурата в определеното време

helena 2 3 4 5 1 · 4 април 2012

Не ,напротив трябва да работи постоянно, защото праща САМО в определен период от време - известия, а за да следи достигането на този определен период от време (проверява полетата в таблица) трябва да работи постоянно :- ) Иначе ще пропуска определените полета от таблицата и се губи инфорамция ...

**capnemo** · 4 април 2012

Не ,напротив трябва да работи постоянно,
защото праща САМО в определен период от време - известия,
а за да следи достигането на този определен период от време (проверява полетата в таблица)
трябва да работи постоянно :- )
Иначе ще пропуска определените полета от таблицата
и се губи инфорамция ...

лично за мен времето е нещо, което се мери с часовник, а не със запис, който чета от базата. Не това е констрейна, който търсите. Пак не обяснявате голямата задача

А за това (достигане на определено условие ) се ползват тригери

helena 2 3 4 5 1 · 4 април 2012

Това време се мери не от записа от базата ,ами от часовника на сървъра и когато този час(от часовника на сървъра) достигне друг час(от базата ) се случва това събитие ! Примерно има в таблицата : Cars : 1. TimeToArrive = 9:40 TimeToStay = 10:40 2.TimeToArrive = 12:00 TimeToStay = 13:00 ... и трябва по часовника на сървъра да се следи за достиганне на времето TimeToStay = 10:40 ам (когато часовника показва 10:40 ам ,тогава прави еди какво си !) Това е ,просто питам как може да работи дадена процедура ПОСТОЯННО : -)

**capnemo** · 4 април 2012

Това време се мери не от записа от базата ,ами от часовника на сървъра

и когато този час(от часовника на сървъра) достигне друг час(от базата ) се случва това събитие !

Примерно има в таблицата :

Cars :

1. TimeToArrive = 9:40 TimeToStay = 10:40

2.TimeToArrive = 12:00 TimeToStay = 13:00

...

и трябва по часовника на сървъра да се следи за

достиганне на времето TimeToStay = 10:40 ам (когато

часовника показва 10:40 ам ,тогава прави еди какво си !)

Това е ,просто питам как може да работи дадена процедура ПОСТОЯННО : -)

Добре, таблицата се чете от някаква процедура, сетва времената в scheduler за пускане на другата процедура и това е? Не върши ли работа. И се слага един семафор ако има insert/update в таблицата да се пуска първата процедура

helena 2 3 4 5 1 · 4 април 2012

Истината е че си нямам все още идея как се настройва този schedule и какво прави ... Но ще видя след като върши работа : ) Благодаря Ви !

**capnemo** · 4 април 2012

Истината е че си нямам все още идея как се настройва този schedule и какво прави ...
Но ще видя след като върши работа : )

Благодаря Ви !

Ето ви една стартова точка

http://msdn.microsoft.com/en-us/library/ms191439.aspx

**darkterminal** · 4 април 2012

Щом искаш нотификация в MVC-то. Слагай AppFabric-a в апликейшъна и си в джаза. По този начин и сървиса и Web сайта ще работят в един application domain и "разговора" между тях няма да е проблем. Имаш обаче голям дизайн проблем! ASP-то (и MVC-то в частност) работи на pull а не на push принцип. С други думи, когато се извика документа за зареждане, тогава той търси за записана информация в базата. Информацията може да я обработва и записва background процес, от който и да е от описаните от мен 3 по-горе три типа. Най лесно е да направиш Job в Job агента на базата данни. Това обаче, не се смята за добра програмистка практика. трудно се поддържа, трудно се дебъггва, трудно се тества. Пак опираме до AppFabric-а. Ади почети малко и ще дадем още инфо...

helena 2 3 4 5 1 · 4 април 2012

Щом искаш нотификация в MVC-то. Слагай AppFabric-a в апликейшъна и си в джаза. По този начин и сървиса и Web сайта ще работят в един application domain и "разговора" между тях няма да е проблем.

Имаш обаче голям дизайн проблем! ASP-то (и MVC-то в частност) работи на pull а не на push принцип. С други думи, когато се извика документа за зареждане, тогава той търси за записана информация в базата. Информацията може да я обработва и записва background процес, от който и да е от описаните от мен 3 по-горе три типа.

Най лесно е да направиш Job в Job агента на базата данни. Това обаче, не се смята за добра програмистка практика. трудно се поддържа, трудно се дебъггва, трудно се тества. Пак опираме до AppFabric-а.

Ади почети малко и ще дадем още инфо...

Сега ми стана по - ясно ,ще почета за AppFabric-а (че си нямам идея ...) !

Благодаря много !!! :wors:

**darkterminal** · 4 април 2012

Ето ти малко материал за четене! Не обръщай внимание на заглавието, инфото вътре е добро и лесно за смилане. Номера е да регистрираш като плъгин (в материала пише как) едно класче, в чийто стартиращ метод връткаш един loop (loop-а ще го отвориш в отделен Thread за да работят нещата). Вътре в цикъла ще се намира кодът който вика желаната от теб процедурка (или през ADO.NET или през EF), след което треда ще заспива за няколко секунди Thread.Sleap(<milliseconds_to_sleep>);.

Хайде - Успех!

**capnemo** · 4 април 2012

Щом искаш нотификация в MVC-то. Слагай AppFabric-a в апликейшъна и си в джаза. По този начин и сървиса и Web сайта ще работят в един application domain и "разговора" между тях няма да е проблем.

Имаш обаче голям дизайн проблем! ASP-то (и MVC-то в частност) работи на pull а не на push принцип. С други думи, когато се извика документа за зареждане, тогава той търси за записана информация в базата. Информацията може да я обработва и записва background процес, от който и да е от описаните от мен 3 по-горе три типа.

Най лесно е да направиш Job в Job агента на базата данни. Това обаче, не се смята за добра програмистка практика. трудно се поддържа, трудно се дебъггва, трудно се тества. Пак опираме до AppFabric-а.

Ади почети малко и ще дадем още инфо...

Дарки, ти изби рибата, един чисто дейтабейзов джоб го метна на майната си. То за това има DBA и девелопери, едните правят едни, другите друго.

**darkterminal** · 4 април 2012

Капитане, базата данни да си се грижи за данните, апликейшън леъра да си се грижи за бизнес логиката. Това е правило старо като света! Всичко трябва да е добре разделено и защитено, без да се губи кохезивността на модела. Така получавам възможност за дебъгване и за юнит тестване. Да не говорим за параметризация и финна регулация на права за достъп и изпълнение от потребители нефигуриращи в домейна или в сървъра. Всички тези аспекти здраво куцат при Job сълюшъна. Просто защото, той не е предвиден за такива задачи. Макар, че както казах вече, не го изключвам от възможностите. Ако ще правя нещо малко и набързо, което няма усърдно да се ползва, ще употребя job-а и аз. В MSSQL света, Job Agent-а е прието да се ползва преди всичко за изпълнение на административни задачи, като бекъп, реиндексиране, репликиране и подобни задачи. DBA-тата да си гледат DBA-вската работа, а девелопърите - девелопърската

**capnemo** · 4 април 2012

Капитане, базата данни да си се грижи за данните, апликейшън леъра да си се грижи за бизнес логиката. Това е правило старо като света! Всичко трябва да е добре разделено и защитено, без да се губи кохезивността на модела. Така получавам възможност за дебъгване и за юнит тестване. Да не говорим за параметризация и финна регулация на права за достъп и изпълнение от потребители нефигуриращи в домейна или в сървъра. Всички тези аспекти здраво куцат при Job сълюшъна. Просто защото, той не е предвиден за такива задачи. Макар, че както казах вече, не го изключвам от възможностите. Ако ще правя нещо малко и набързо, което няма усърдно да се ползва, ще употребя job-а и аз. В MSSQL света, Job Agent-а е прието да се ползва преди всичко за изпълнение на административни задачи, като бекъп, реиндексиране, репликиране и подобни задачи. DBA-тата да си гледат DBA-вската работа, а девелопърите - девелопърската

Дарки, нямаш грижи нито за дебъгване (скоро го правих с един 1000 реда PL/SQL), нито за права (поне при Оракъл), и това е точно работа за базата, погледни логиката, тригера, сторед процедурите, всичко е компактно и интегрирано, иначе трябва да мяташ данни като щур

**darkterminal** · 4 април 2012

Е така де, ама на базата нито и е работа да се занимава с дебъгване, нито с права на потребители регистрирани извън сървъра (примерно правата на потребителите на една CRM система), Откъде накъде, Job Agent-а ще знае въобще за тези потребители и за техните привилегии? За тригери, Капитане въобще не ми говори. Те отдавна са признати за хак, който е редно да се избягва, поне в ентерпрайз девелопмента. Това е обект с измамен чар за използване. На практика се получава накъсана и трудна за поддръжка логика. Това, за което стават са само бързи кърпежи на стари системи и бърза интеграция. Виж сторнатите процедурки не ги отричам, но такива с по 1000 реда... Определено има нещо нередно в тази процедура. Бизнес логиката се държи в бизнес леъра. А пък с АппФабриката всичко рънка в един процес, дебъгваш един процес, грижиш се за един процес, можеш да размножиш и дистрибутираш този процес на много сайтове и уеб-ферми, правата и сигурността се мениджват където трябва. Разбира се, от сториджа до апликейшъна се пренасят само данните които е необходимо. За масаж на данни и за трансформация е редно да се грижат други бекграунд апликейшъни, но ако обърнеш внимание, и те са отделни апп-ки, а не разчитат на Job Agent-а. Та така...

**capnemo** · 4 април 2012

Е така де, ама на базата нито и е работа да се занимава с дебъгване, нито с права на потребители регистрирани извън сървъра (примерно правата на потребителите на една CRM система), Откъде накъде, Job Agent-а ще знае въобще за тези потребители и за техните привилегии? За тригери, Капитане въобще не ми говори. Те отдавна са признати за хак, който е редно да се избягва, поне в ентерпрайз девелопмента. Това е обект с измамен чар за използване. На практика се получава накъсана и трудна за поддръжка логика. Това, за което стават са само бързи кърпежи на стари системи и бърза интеграция. Виж сторнатите процедурки не ги отричам, но такива с по 1000 реда... Определено има нещо нередно в тази процедура. Бизнес логиката се държи в бизнес леъра. А пък с АппФабриката всичко рънка в един процес, дебъгваш един процес, грижиш се за един процес, можеш да размножиш и дистрибутираш този процес на много сайтове и уеб-ферми, правата и сигурността се мениджват където трябва. Разбира се, от сториджа до апликейшъна се пренасят само данните които е необходимо. За масаж на данни и за трансформация е редно да се грижат други бекграунд апликейшъни, но ако обърнеш внимание, и те са отделни апп-ки, а не разчитат на Job Agent-а. Та така...

Дарки, получил си плюс от Хелена немного заслужено

Ако говорим за MSSQL може и да си прав, но тригери, сторед процедури и т.н. си стоят в базата (особено при Оракъл), няма при всеки инсърт/ъпдейт да разнасям данни до някакъв си ап само за да ми каже какво да правя с тях, това си е типична работа на базата, да работи с данните. А виж с тяхно сечение е работа на приложението. Ако знаеш как работи хадууп, нетеца и т.н. ще разбереш какво имам предвид

**darkterminal** · 4 април 2012

Не си чел внимателно какво пиша. Аз изрично подчертавам, че до апликейшъна се пренасят изключително и само необходимите данни! Освен това тригерите и сторед процедурите, няма къде другаде да се намират, освен в базата данни, тъй като те там си живеят (там са дефинирани и там се изпълняват). Апликейшъна извиква сторнатите процедури, които му предоставят само необходимите за операцията данни, а той от своя страна се грижи да даде само необходимите за съхранение данни на SQL сървъра (може и през сторнати процедури). До тук, надявам се няма разлика в това което казваме. Това, което аз предлагам да се направи различно, е кой да се грижи за скеджула, по който да се извиква сторнатата процедура на helena. Посочих и куп причини защо, бих предпочел да е така. Всъщност, не аз съм измислил този ентерпрайз патърн. За тригерите отделно споменах, защо не е препоръчително да се ползват и това, отново не е само мое мнение и не се отнася само за MSSQL. Тригера прекъсва натуралното флоу на процеса и го прави труден за проследяване, предвиждане и поддръжка, добавя перформанс пеналтис и разпростира скоупа на транзакцията (което води до цял куп допълнителни пеналтис) във всяка една база данни!

**capnemo** · 5 април 2012

... Това, което аз предлагам да се направи различно, е кой да се грижи за скеджула, по който да се извиква сторнатата процедура на helena. Посочих и куп причини защо, бих предпочел да е така. Всъщност, не аз съм измислил този ентерпрайз патърн. За тригерите отделно споменах, защо не е препоръчително да се ползват и това, отново не е само мое мнение и не се отнася само за MSSQL. Тригера прекъсва натуралното флоу на процеса и го прави труден за проследяване, предвиждане и поддръжка, добавя перформанс пеналтис и разпростира скоупа на транзакцията (което води до цял куп допълнителни пеналтис) във всяка една база данни!

Нормално е да има такива ефекти върху базата, но личното ми разбиране е че именно тази таблица няма да се променя често и няма да има много записи. И с един тригер в нея и скедул по-лесно ще се осъществи консистентност на такава "транзакция". Иначе прекъсване в комуникационен канал между база и апп може да предизвика проблем

helena 2 3 4 5 1 · 5 април 2012

... личното ми разбиране е че именно тази таблица няма да се променя често и няма да има много записи. И с един тригер в нея и скедул по-лесно ще се осъществи консистентност на такава "транзакция". Иначе прекъсване в комуникационен канал между база и апп може да предизвика проблем

В тази таблица постоянно ще "нахлуват" нови записи и упдейтване на стари ,т.е. постоянно ще има движение на записите

**capnemo** · 5 април 2012

В тази таблица постоянно ще "нахлуват" нови записи и упдейтване на стари ,т.е. постоянно ще има движение на записите

Дефинирай постоянно, защото за мен това е дефиниция за непрекъснатост, а не за честота

helena 2 3 4 5 1 · 5 април 2012

Дефинирай постоянно, защото за мен това е дефиниция за непрекъснатост, а не за честота

Под постоянно исках да отговоря на това ваше изказване : "личното ми разбиране е че именно тази таблица няма да се променя често и няма да има много записи" ,НО иначе сте прав не използвах правилната дума

...

Въпреки това мисля ,че се разбра ЯСНО ,че в тази таблица ЧЕСТО ще "нахлуват" записи ...

Вход

Архивирана тема

Как една stored procedure да работи постоянно ?

Препоръчан отговор

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

darkterminal 30713

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

darkterminal 30713

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

helena 2 3 4 5 1 35

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

darkterminal 30713

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

darkterminal 30713

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

capnemo 44920

Сподели този отговор

Линк към този отговор

Сподели в други сайтове

darkterminal 30713

Сподели този отговор

Линк към този отговор

Сподели в други сайтове