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 ««12345»»»

The CLR in SQL Server 2005 Expand / Collapse
Author
Message
Posted Monday, May 02, 2005 10:36 AM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, April 12, 2012 11:03 AM
Points: 455, Visits: 45
I have yet to see a good example of what can be done with the SQLCLR that can't be accomplished with some T-SQL savvy.

I think the idea of the CLR in SQL Server was one of those ideas someone brings up in a staff meeting, sounds great to management, and sounds even better to marketing.

In addition, I believe the SQLCLR is a gross violation of the DRY principle.

What's next? - the SMSCLR, the VSCLR, the POWERPOINTCLR, the COM+CLR, *8,.,

While a developer myself, I have never blamed a DBA for being territorial about the Back End. However, since technology drives new features; and vendors decide how they implement them, chances are, in the end, we will be puting up with crap in the Back End (no pun intended =).



{Francisco}
Post #179242
Posted Monday, May 02, 2005 10:48 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, March 10, 2014 1:21 PM
Points: 885, Visits: 1,526

Straegen, I believe that you recieved the responses you did because your first few posts indicated that you believed that T-SQL was headed for the grave in it's entirety and rightfully so.  In the lats post you somehwat contreadicted your early posts by stating

'I agree queries will still be run, but that is what they will be... queries'

I'm not so sure that the rest of us understand exactly what your stance is, I know I don't and maybe it's just me.  In one post you say that it's time for T-SQL to head towards the grave and in another you state that it will still be used for queries.  So what exactly is your stance on this issue? Are you saying that it's time for T-SQL to disappear from the face of the earth or are you saying that it's time for T-SQL to be used strinctly for working directly with relational data?

 

Thanks

Ed



Kindest Regards,

A Democracy works great until the day you find yourself on the sheep side of a vote between 5 wolves and 4 sheep on what’s for dinner when neither have eaten in many days. A free Republic where the rights of the few and the individual are protected is the only one in which Freedom and Prosperity for all have a chance to blossom.
Post #179249
Posted Monday, May 02, 2005 11:22 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 4:31 PM
Points: 32,780, Visits: 14,941
Francisco,

I haven't seen may good cases, but a few interesting ones were check constraints on tables. Trying to be sure that an IP address was valid, or that a phone number conformed to a valid format (either hyphens or dots), etc. These types of string manipulations are very complex in T-SQL and trivial in C# or VB.NET. I also suspect that some financial or complex Analysis services rollups will be much easier in a CLR languange than T-SQL or MDX.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #179261
Posted Monday, May 02, 2005 12:28 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 14, 2008 6:43 PM
Points: 14, Visits: 3

No contridiction from my viewpoint.  SQL and T-SQL aren't the same thing.  I don't think SQL is going anywhere since it does what it does quite well, but the way we access and manage the results from queries, loops, variables, error handling, transactions, etc (i.e. T-SQL) will likely shift to CLR in the long term.  If you haven't programmed C# or VB.net, you will likely fall in love with them once you see how much easier data manipulation can be in a language that was designed for it.

I don't have a problem with someone disagreeing with me since my points are only speculation, but that first poster who called me silly either didn't read my post well and missed the point or has a screw loose.  I am not being irrational.  My point is that anyone who uses both TSQL and some other next gen language will tell you that TSQL is weak in many areas and it is time to get something better.  It isn't marketing or some spitball idea (at least not completely).  Programmers have been asking for a real language in SQL for quite a while.

The original author of the story made it sound like CLR wasn't "all bad" and I believe that CLR integration is great.  That is where our points divulge.  My additional thoughts about TSQL going the way of dino are just thoughts that reminded me of the old COBOL switch (back when more lines of code were written in COBOL than any other language).




Post #179285
Posted Monday, May 02, 2005 12:42 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 14, 2008 6:43 PM
Points: 14, Visits: 3

This gets back to my COBOL arguement.  COBOL could do almost all the things that next gen languages could do, but it wasn't adept at it.  I believe T-SQL suffers from the same problem.  Complex loops, variable management, inline procedures, ability to create and manage objects can all be done or simulated in T-SQL.  It is just easier to do in other next gen languages.

This does get into another discussion flying around.  When I refer to SQL, I am referring to the set based SELECT, UPDATE, INSERT, DELETE statements.  When I refer to T-SQL being replaced by CLR, I am referring to the logical part of SQL such as flow control, variables, etc that normally reside in stored procedures.  I know they are the same animal inside SQL Server and that seems to be leading to some confusion. 




Post #179291
Posted Monday, May 02, 2005 12:43 PM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, April 12, 2012 11:03 AM
Points: 455, Visits: 45
Steve,
I would not consider those examples "GOOD".

-- i.e. check constraint
([Telephone] like '([0-9][0-9][0-9])[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]' or
[Telephone] like '[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9][0-9][0-9][0-9]')

You can do similar things for IPs. I guess it is a bit complex but C# or VB code is not going to be, by any order of magnitude, any rosier.



{Francisco}
Post #179293
Posted Monday, May 02, 2005 1:18 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 14, 2008 6:43 PM
Points: 14, Visits: 3

The ability to import an assembly and reuse code gives CLR a huge advantage.  Think about it...  one unified language in development, application automation such as Excel and Office, extensions in products like Exchange and finally integrated into systems such as SQL Server.  How long do you think it is before any technical person can go without knowing CLR?  In ten years, knowing C# or VB.net will be common even for many savy end users.  By contrast I still know developers who use SQL Server who couldn't do a FETCH in SQL without googling it?  MS is clearly pushing CLR to replace the logical aspects of TSQL.  




Post #179303
Posted Monday, May 02, 2005 1:44 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 4:31 PM
Points: 32,780, Visits: 14,941
Your example can handle some things, but it's not as clean, not does it easily work with non-US phones, etc. Using a CLR language and regular expressions, it's more flexible and clean. Arguable, less intuitive for a DBA, which is why I'm not sold, but there are functions that are easier in another language.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #179311
Posted Monday, May 02, 2005 2:44 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, March 21, 2014 7:45 AM
Points: 1,138, Visits: 698
True business logic has only one place, and that's the database. Databases are designed to be shared amongst applications across an enterprise, and to be the final arbiter of good and bad data. Why do developers insist that logic should be duplicated (re-programmed!) again and again whenever a new application is created? If something is truly a business rule -- and not an application rule -- that logic belongs in the database, where it can be constrained properly, exactly once.

--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #179324
Posted Monday, May 02, 2005 2:52 PM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Monday, March 23, 2009 9:44 AM
Points: 179, Visits: 22
Just off the top of my head, the power of placing an application on an end user's desktop via web standards is reason enough to program business logic in JavaScript.

Talk about a liberating experience.





Everett Wilson
ewilson10@yahoo.com
Post #179325
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse