T-SQL for everything??
-
Hi, I've just moved across divisions at a big corporate bank, as a result of a request by the Divisional IT head... . .not that any of that is important :zzz: After spending almost 2 weeks here now, I've noticed somethign rather disturbing... 80% of the processing is being done on the SQL Server??? Admittingly . .the result of legacy, and based on the strengths of the senior developers here. The primary user application is a custom built VB.net/C# combo Windows application. But all its really used for is presentation of the ultimate results, all processing is handled by stored procedures within MSSQL Server 2000... :omg: . . including all : Batch processing (scheduled Stored Procedures that run for up to 7 days at a time!!), Text\XML file generation (tons of BCP commands, etc), Email\FTP management :omg: now.. i've been a software engineer for about 7 years.. and correct me if i am wrong.. but surely software practices have advanced a bit beyond this, and there are better ways to do all of these! My primary task for the first few weeks has been to do an assessment of the environment, and make some recommendations as to how things can be achieved in a better, more streamlined, more econmical manner. this is just one of the main issues we're facing here, source code repositories dont exist, no proper release and QA processes are in place.. blah blah blah... Alright.. enough blabbing, back to my original question... is SQL Server really the best place to conduct your primary business logic implementation?? I've always been of the opinion that stored procs should be used for CRUD, and only deviate from this when absolutely necessary... some advice please. . . Am I wrong here?
-
Hi, I've just moved across divisions at a big corporate bank, as a result of a request by the Divisional IT head... . .not that any of that is important :zzz: After spending almost 2 weeks here now, I've noticed somethign rather disturbing... 80% of the processing is being done on the SQL Server??? Admittingly . .the result of legacy, and based on the strengths of the senior developers here. The primary user application is a custom built VB.net/C# combo Windows application. But all its really used for is presentation of the ultimate results, all processing is handled by stored procedures within MSSQL Server 2000... :omg: . . including all : Batch processing (scheduled Stored Procedures that run for up to 7 days at a time!!), Text\XML file generation (tons of BCP commands, etc), Email\FTP management :omg: now.. i've been a software engineer for about 7 years.. and correct me if i am wrong.. but surely software practices have advanced a bit beyond this, and there are better ways to do all of these! My primary task for the first few weeks has been to do an assessment of the environment, and make some recommendations as to how things can be achieved in a better, more streamlined, more econmical manner. this is just one of the main issues we're facing here, source code repositories dont exist, no proper release and QA processes are in place.. blah blah blah... Alright.. enough blabbing, back to my original question... is SQL Server really the best place to conduct your primary business logic implementation?? I've always been of the opinion that stored procs should be used for CRUD, and only deviate from this when absolutely necessary... some advice please. . . Am I wrong here?
LyndonSubroyen wrote:
is SQL Server really the best place to conduct your primary business logic implementation??
It depends on what that logic is. The project I'm working on at the moment has most of the processing in SQL Server because SQL is the most efficient way of implementing what I want to do. Its a batch process that takes about 24 hours to run. There is no way I could achieve that in C# so I let SQL Server do the job it is designed to do - process vast amounts of data. Other aspects you've mentioned could be done better in C# so there is definitely room for improvement.
"On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question." --Charles Babbage (1791-1871) My: Website | Blog
-
Hi, I've just moved across divisions at a big corporate bank, as a result of a request by the Divisional IT head... . .not that any of that is important :zzz: After spending almost 2 weeks here now, I've noticed somethign rather disturbing... 80% of the processing is being done on the SQL Server??? Admittingly . .the result of legacy, and based on the strengths of the senior developers here. The primary user application is a custom built VB.net/C# combo Windows application. But all its really used for is presentation of the ultimate results, all processing is handled by stored procedures within MSSQL Server 2000... :omg: . . including all : Batch processing (scheduled Stored Procedures that run for up to 7 days at a time!!), Text\XML file generation (tons of BCP commands, etc), Email\FTP management :omg: now.. i've been a software engineer for about 7 years.. and correct me if i am wrong.. but surely software practices have advanced a bit beyond this, and there are better ways to do all of these! My primary task for the first few weeks has been to do an assessment of the environment, and make some recommendations as to how things can be achieved in a better, more streamlined, more econmical manner. this is just one of the main issues we're facing here, source code repositories dont exist, no proper release and QA processes are in place.. blah blah blah... Alright.. enough blabbing, back to my original question... is SQL Server really the best place to conduct your primary business logic implementation?? I've always been of the opinion that stored procs should be used for CRUD, and only deviate from this when absolutely necessary... some advice please. . . Am I wrong here?
LyndonSubroyen wrote:
is SQL Server really the best place to conduct your primary business logic implementation??
My personnel view is Yes! Even it all depends on the Organization ,Requirements of the application and all the other facotrs "Aim to go where U have never been B4 and Strive to achieve it" http://groups.yahoo.com/subscribe/dotnetforfreshers http://himabinduvejella.blogspot.com
-
Hi, I've just moved across divisions at a big corporate bank, as a result of a request by the Divisional IT head... . .not that any of that is important :zzz: After spending almost 2 weeks here now, I've noticed somethign rather disturbing... 80% of the processing is being done on the SQL Server??? Admittingly . .the result of legacy, and based on the strengths of the senior developers here. The primary user application is a custom built VB.net/C# combo Windows application. But all its really used for is presentation of the ultimate results, all processing is handled by stored procedures within MSSQL Server 2000... :omg: . . including all : Batch processing (scheduled Stored Procedures that run for up to 7 days at a time!!), Text\XML file generation (tons of BCP commands, etc), Email\FTP management :omg: now.. i've been a software engineer for about 7 years.. and correct me if i am wrong.. but surely software practices have advanced a bit beyond this, and there are better ways to do all of these! My primary task for the first few weeks has been to do an assessment of the environment, and make some recommendations as to how things can be achieved in a better, more streamlined, more econmical manner. this is just one of the main issues we're facing here, source code repositories dont exist, no proper release and QA processes are in place.. blah blah blah... Alright.. enough blabbing, back to my original question... is SQL Server really the best place to conduct your primary business logic implementation?? I've always been of the opinion that stored procs should be used for CRUD, and only deviate from this when absolutely necessary... some advice please. . . Am I wrong here?
Ripping out existing infrastructure just to do things "correctly" is usually bad, especially if things are working. Probably better to put controls in place for stored procedures and backend processes. E.g. Use VSS to track all changes to the database. I have been a huge user of T-SQL in the past, and it served me well. Some things just rip along when run right on the database server. You're really just writing your BL in T-SQL. Not that different than running a webservice host directly on the SQL Server, no? With SQL 2005 you can even write you procs in .NET. That being said, it's really hard to separate your TSQL stuff from the database later if you need to scale out. Forget about porting to another rdbms. I have reformed from my past TSQL sins, and don't intend to go back. Unless of course the environment or situation calls fors it.;)