Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
tfountain
Constraint Violating Yak Guru
491 Posts |
 Posted - 2008-07-10 : 16:01:08
|
| Implement CLR or not to implement CLR, that is the question.Ok, enough with the lame Shakespear but in regards to implementing this functionality in an enterprise environment. What are your thoughts and opinions on this feature and how do you control it?My situation is this, I am the DBA for our shop that consists of local development teams and offshore development teams in India. While we have standards, policies and procedures I personally have a tough time enabling this functionality and opening up developers to deploy .NET code on the database server. I'm hoping the pros here can share their thoughts, ideas and opinions on this matter. Maybe I'm just being to cautious, maybe I'm not but I'd like to see what the general concensus is. |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
Zack
Starting Member
26 Posts |
Posted - 2008-07-11 : 10:42:13
|
| Ask the development team why they want to use CLR instead of standard SPs. Once you have some idea why and what kind of stuff they want to deploy you can better make the decision. |
 |
|
|
tfountain
Constraint Violating Yak Guru
491 Posts |
Posted - 2008-07-11 : 17:35:54
|
quote:
Originally posted by tkizer
It depends on what the CLR is doing. I'm all for CLR code as long as they don't require that trustworthy bit.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog
What about writing processes that run and queries for files on the file system (that reside on other servers) on some interval and imports data into the database? Personally, IMO, they should just write a .NET app that runs as a windows service and run that on a completely different machine.To break it down, anything that is simple and more of a utility concept I really would not have anything against. But knowing how a developer operates, once this gate is open it's open for anything to be put in (like the above example). And this is what I would want to prevent.So I guess the question are:Do you allow CLR on your database?Do you care what code runs in CLR on your database?Do you have controls in place to enforce what code runs via CLR on your database? |
|
|
|
tfountain
Constraint Violating Yak Guru
491 Posts |
Posted - 2008-07-11 : 17:40:45
|
quote:
Originally posted by Zack
Ask the development team why they want to use CLR instead of standard SPs. Once you have some idea why and what kind of stuff they want to deploy you can better make the decision.
Thank you Mr. Obvious... :)I already know what they want to do, and I'm just not comfortable with it. What I'm trying to do here is gauge what the overall opinion is of this feature. Considering we are in an enterprise environment that utilizes a variety of monitoring and gauge various performance metrics. And not to mention the various SLAs our clients have us contracted to (which is why we scrutinize things like this).So with this in mind hopefully this clarifies what information I am interested in. |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2008-07-11 : 17:46:25
|
quote:
Originally posted by tfountain
quote:
Originally posted by tkizer
It depends on what the CLR is doing. I'm all for CLR code as long as they don't require that trustworthy bit.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog
What about writing processes that run and queries for files on the file system (that reside on other servers) on some interval and imports data into the database? Personally, IMO, they should just write a .NET app that runs as a windows service and run that on a completely different machine.To break it down, anything that is simple and more of a utility concept I really would not have anything against. But knowing how a developer operates, once this gate is open it's open for anything to be put in (like the above example). And this is what I would want to prevent.So I guess the question are:Do you allow CLR on your database?Do you care what code runs in CLR on your database?Do you have controls in place to enforce what code runs via CLR on your database?
Your file system/remote servers issue would require elevated permissions, which is that trustworthy bit I mentioned. This would not be allowed in our environment except for DBA-type stuff on a DBA-type database. See my disk space blog for an example: http://weblogs.sqlteam.com/tarad/archive/2007/12/18/60435.aspx1. Yes.2. Yes.3. No, however permissions will prevent them from doing too much.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog |
|
|
|
Zack
Starting Member
26 Posts |
Posted - 2008-07-14 : 07:52:10
|
quote:
Originally posted by tfountainThank you Mr. Obvious... :)
:) Good thing I wasn't drinking coffee when I read that statement or I'd be cleaning my keyboard now....Just because you can implement CLR doesn't mean you should. That's the point I was trying to make when I said to ask them why they wanted to use CLR instead of a standard SP. |
|
|
|
|
|
|
|
|
Implementing CLR