|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
TSQL or CLR? Interested in hearing opinons...CLR can enhance your development in specific situations, but I would use it
only on an as needed basis. CLR programming is not familariar to many (perhaps most) database developers or DBAs, so you have a smaller pool of potential developers to draw from when debugging or extending the system. This can perhaps mean more downtime, missed deadlines, and higher priced contractors. Show quote "Charlie@CBFC" <fineblu***@verizon.net> wrote in message news:eF55CG1TGHA.1160@TK2MSFTNGP09.phx.gbl... > Thanks, > Charlie > "Charlie@CBFC" <fineblu***@verizon.net> wrote in news:eF55CG1TGHA.1160 @TK2MSFTNGP09.phx.gbl:This is not an either/or situation. CLR is good for certain things, T-SQL for others. CLR is just another weapon in the arsenal of a good db developer/DBA. Niels -- ************************************************** * Niels Berglund * http://staff.develop.com/nielsb * nielsb at develop dot com * "A First Look at SQL Server 2005 for Developers" * http://www.awprofessional.com/title/0321180593 ************************************************** What are you trying to do, pick one and only one? Don't do it.
In most cases, in my experience, sticking with T-SQL is the way to go. Anything that involves set-based processing is most likely better off staying the way it is. There are some scenarios where CLR will yield better performance, and these are usually areas where T-SQL has traditionally been sub-par. String parsing, concatenating, regular expressions, iterative/recursive operations, some others. My main frustration with the original thrust of CLR onto the database world is that Microsoft tended to choose very poor examples for, hey, look what you can do with the CLR. In most cases, these are things that should have stayed in T-SQL. Thankfully, the development community in general has followed up with several examples of more approriate usage of CLR. Depending on your environment/shop, it may or may not be worth the investment/learning curve etc. There is definitely no advantage to saying, okay, bye bye T-SQL, we're only using CLR from now on. At the same time, there is no advantage to saying, okay, CLR is never going to touch my database. Show quote "Charlie@CBFC" <fineblu***@verizon.net> wrote in message news:eF55CG1TGHA.1160@TK2MSFTNGP09.phx.gbl... > Thanks, > Charlie > Well put, Aaron.
I'd just like to add one more bit: Even with CLR, you still use TSQL to access the data. And you still want to use TSQL stored procedures in the end. I.e., you don't want to do SELECT etc from the CLR code, for several reasons, where one reason is that you'd have to grant the end user permissions on the tables... -- Show quoteTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ Blog: http://solidqualitylearning.com/blogs/tibor/ "Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message news:%23AGWgX2TGHA.4956@TK2MSFTNGP09.phx.gbl... > What are you trying to do, pick one and only one? Don't do it. > > In most cases, in my experience, sticking with T-SQL is the way to go. Anything that involves > set-based processing is most likely better off staying the way it is. > > There are some scenarios where CLR will yield better performance, and these are usually areas > where T-SQL has traditionally been sub-par. String parsing, concatenating, regular expressions, > iterative/recursive operations, some others. > > My main frustration with the original thrust of CLR onto the database world is that Microsoft > tended to choose very poor examples for, hey, look what you can do with the CLR. In most cases, > these are things that should have stayed in T-SQL. Thankfully, the development community in > general has followed up with several examples of more approriate usage of CLR. > > Depending on your environment/shop, it may or may not be worth the investment/learning curve etc. > There is definitely no advantage to saying, okay, bye bye T-SQL, we're only using CLR from now on. > At the same time, there is no advantage to saying, okay, CLR is never going to touch my database. > > > > > "Charlie@CBFC" <fineblu***@verizon.net> wrote in message > news:eF55CG1TGHA.1160@TK2MSFTNGP09.phx.gbl... >> Thanks, >> Charlie >> > >  |
|||||||||||||||||||||||
Other interesting topics