tags:

views:

84

answers:

3

I have a SQL Server stored procedure which has been in use for years. This stored procedure calls lots of other procedures. I would like to extract each inside procedure one at a time and implement its business logic to a .NET Class project.

In order to do that, I have to call .NET assembly from parent stored procedure and the returned result will be used by parent procedure. Since SQL Server 2005 and higher has CLR integration, so I think, executing .NET assembly inside stored procedure [or any Database objects] should not be a big deal, can you please point me some references where i can find examples or article to implement it?

Thank you very much for your help .

+3  A: 

I really feel that this would be an inappropriate use of SQL CLR. The purpose of CLR integration is to support complex data types and operations that are normally very hard to do in pure SQL (such as sequences, regular expressions, hierarchy, geospatial, etc.) Not to implement a domain model in your database.

Domain models and business logic are separate from relational/data models. They should be in a proper business tier of some sort. Don't hack them into a database using the CLR.

(Note: I use SQLCLR a fair bit. I am not railing on CLR integration. I just don't think that this question reflects a wise design decision.)

Aaronaught
Agree with these points - definitely look into what CLR has to offer, and get a feel for when it should and shouldn't be used over TSQL.
AdaTheDev
Not to mention it sounds like a potential performance headache
RobS
@Rob Sanders: Someday I'll write about how I was able to leverage the CLR for an ~80% size reduction and 10-12x speed/throughput improvement. ;) Used carefully and judiciously it can be an amazing tool that puts SQL Server way ahead of the curve, but I've also seen some truly frightening CLR hacks from people who didn't quite "get it". I think part of the problem is a lack of tested guidelines and useful real-world examples.
Aaronaught
@Aaronnaught Couldn't agree more. Right tool for the job is a good approach, I've seen it go both ways as well. You are so right about a lack of real world examples!
RobS
@Aaronaught it really depends on what you are moving the code to CLR for... there are some things it does extremely well (e.g. string handling) and there are other things it does extremely poorly (e.g. most data access). Like Rob says it can go either way; it can be a helpful tool or an absolute nightmare.
Aaron Bertrand
A: 

I think you should use SQL Server Integration Services (SSIS). As far as I understand, it solves this case, to orchestrate the procedure calls and gives you much more too..

I'm not too sure if moving this decision outside the db layer is a good decision.

Hope it helps..

Satya