Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456»»

The SQLCLR Impact Expand / Collapse
Author
Message
Posted Friday, February 21, 2014 3:48 PM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, November 4, 2014 6:10 PM
Points: 23, Visits: 108
At one time I used a CLR string aggregator (catenate with commas between) with code taken from the SQL Server developer samples, and for a while I used an open source CLR geospatial extension (can't remember what it did). I never developed SQL Server CLR code from scratch.

These uses were not terribly important, but when I tried moving a subset of the database to SQL Azure (using the limited usage that came with my MSDN Premium subscription), I couldn't do it because of those extra assemblies. All I was doing was experimenting to become more familiar with cloud services, but I ended up concluding that, at least at that time CLR and cloud did not mix.
Post #1544206
Posted Friday, February 21, 2014 3:57 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:08 PM
Points: 35,593, Visits: 32,187
eric.notheisen (2/21/2014)
I worked on a project for Wells Fargo a few years ago. We had a database developer who used CLR procedures for 60 percent of his stored procs. We found the performance hit to be minimal and the flexibility to be superior. In my current work I have used CLR procedures several times when I needed to recursively look at or process .data


Flexible how and superior to what?


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1544208
Posted Friday, February 21, 2014 4:18 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 9:51 AM
Points: 5,446, Visits: 7,616
Never personally used it. Haven't even booted up the interface. Never had to.

One of my vendors who runs our SoR seems to use it pretty heavily. Haven't seen any particular performance concerns due to the CLR on that system. That's mostly because the bottlenecks on that one are elsewhere.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1544211
Posted Friday, February 21, 2014 5:40 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, November 4, 2014 10:12 AM
Points: 124, Visits: 2,447
We installed one - a RegEx string handler to replace unacceptable characters. I want to put another in - a splitter, but there's no pressing need, so it's not on the radar yet.

Mark
Just a cog in the wheel.
Post #1544218
Posted Friday, February 21, 2014 6:55 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 12:42 PM
Points: 3,388, Visits: 2,021
We've implemented a couple CLR functions for string concatenation, string splitting and parsing and that is it. They are rarely used. We don't see a great need to use CLR.
Post #1544223
Posted Saturday, February 22, 2014 2:50 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, February 22, 2014 8:59 PM
Points: 1, Visits: 28
Yes, we do it for the SQL Mail
Post #1544240
Posted Saturday, February 22, 2014 3:52 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 11:46 AM
Points: 2,419, Visits: 6,708
My 2 cents: SQLCLR is like any other hammer, when you hold it, every thing looks like a nail! I think it is a valuable addition to the SQL Server and like any technology, when used properly it rocks. But having outperformed CLR with set based code in certain cases and also my best efforts in other being up to 3 or 4 times slower, one realizes that there are specific nails for specific hammers. The down side in my opinion is not the technology itself but the application of it. Far to often we use what we are most comfortable with, not necessarily what is the most applicable.
Post #1544263
Posted Monday, February 24, 2014 7:30 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Sunday, November 23, 2014 2:48 PM
Points: 1,754, Visits: 4,966
Jeff Moden (2/21/2014)
eric.notheisen (2/21/2014)
I worked on a project for Wells Fargo a few years ago. We had a database developer who used CLR procedures for 60 percent of his stored procs. We found the performance hit to be minimal and the flexibility to be superior. In my current work I have used CLR procedures several times when I needed to recursively look at or process .data


Flexible how and superior to what?

When it comes to databases, scalability, extensibility, and maintainability are good, but flexibility can have some negative connotations.
Post #1544518
Posted Monday, February 24, 2014 10:00 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 9:02 AM
Points: 2,915, Visits: 1,849
SQL# contains just about everything I'd want to do that isn't already in T-SQL.

It think SQLCLR has yet to have its day. I firmly believe that it has potential for developing a statistics toolkit and that requirement has yet to come to the fore.

We did some work with SQLCLR and service broker some time ago but it didn't catch on.

Personally I think that where there is separation between the various roles of a DBA and the roles of developers you won't get SQLCLR adoption. If you had developers with a strong database skillset then blending the two worlds together would be much more likely.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1544625
Posted Tuesday, February 25, 2014 1:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:33 AM
Points: 5,754, Visits: 3,673
David.Poole (2/24/2014)
...If you had developers with a strong database skillset then blending the two worlds together would be much more likely.


I could take exception to that!!!


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1544796
« Prev Topic | Next Topic »

Add to briefcase «««23456»»

Permissions Expand / Collapse