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 Thursday, April 14, 2005 6:02 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 5:38 PM
Points: 31,368, Visits: 15,834
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/theclrinsqlserver2005.asp






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #174904
Posted Monday, May 2, 2005 12:52 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Wednesday, December 17, 2008 8:34 AM
Points: 108, Visits: 6
I'm with you on this one Steve, I also think it will bring more head-aches than happy customers as developers (in general) love technology not business so they tend to use the latest technologies without fully understanding them as using them helps them fully understand them! The catch 22. It reminds me of XML in the database and how loads of developers started getting it and storing it in databases for no apparent reason to me than to help build their CV...

 

 


regards,
Mark Baekdal
http://www.dbghost.com

http://www.innovartis.co.uk

+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change management for SQL Server

 

 

Post #179095
Posted Monday, May 2, 2005 6:59 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Sunday, October 27, 2013 9:08 AM
Points: 133, Visits: 117

Steve

Totally agree and glad you brought this up. When I first heard about this I assumed that it might be part of an effort to reduce perceived TCO for SQL Server at smaller shops that rely on developers to support the db instead of a full time dba. I've worked at several clients lately, not so small ones too, that did not have what I consider to be a real dba ...sql server was so easy to administer that developers supported the db. That's off the subject and Iwon't go any further down that path  but my initial take on including the CLR was that maybe Microsoft sees the role of the DBA changing. Just my opinion ...Can anybody recommend a good book on dot net?

Mardy    




Post #179163
Posted Monday, May 2, 2005 7:21 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

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

Not buying it.  In many (read most) small companies, the dev is the SQL guy and the software developer.  Most small company devs will leave TSQL quickly since working in one language is easier than two.  It will take longer for large companies to switch as they move slower for good reason, but small companies are usually the first indicators of where the industry is headed.  With the switch to dotNet and many apps being rewritten, it won't take long for TSQL to become CLR code in most shops.  The great news is that TSQL developers willing to make the switch will likely find good jobs over the next decade porting code. 

Also, TSQL is horrible... let me say it again... HORRIBLE as a language.  CLR is better and I speak from experience.  This has been coming for years and all the major commercial SQLs will all switch sooner or later.  I can see MySQL and smaller engines staying in SQL syntax for a while, but it wouldn't suprise me to see some PHP or similar engines being fitted for them as well.

Just like COBOL had to die and VB Classic will soon be pronounced, it is time to stick a fork in a language that should have been dead years ago.  I get that DBAs with little or no programming skill might be worried, but in my experience it isn't the TSQL that keeps a DBA around.  It is the tuning and maintenance which software developers generally don't want to do or are incapable of doing.

My last comment on the subject is don't be an ostrich on this one.  If you do, you will likely pull your head from the sand and realize that a part of your skillset has been rendered obsolete.  I still remember my COBOL friends from the mid 90s saying there is just too much tested COBOL code to replace.  COBOL will be around for my lifetime.  That VB stuff isn't as solid and proven.  Yada... yada... yada.  They all eventually converted and unfortunately for most it was too late.  Being the new kid on the block at age 50 just isn't pretty.




Post #179167
Posted Monday, May 2, 2005 8:05 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, September 22, 2008 7:19 AM
Points: 34, Visits: 8

I cant believe that you are comparing T-SQL to COBOL and attempting to draw a valid conclusion.  The very fact that you would compare two such tools leads me to believe that you have not really developed for a modern RDBMS.  TSQL is a SET based language.  The only people I have ever heard of that complain about the language * do not understand how to use it* and try to use it in a procedural fashion.  There isn't even a mechanisim for performing set operations in COBAL.  The comparison is ridiculous.

Regardless of that silly post, I AM looking forward to CLR integration.  I have had to write complex analysis functions in the past.  I wished for the day I wouldnt have to move large datasets into the client for processing.  Furthermore, I envision CLR integration bringing NOT the Logic Layer to the DB, but the Data Access Layer.  Using TSQL to hydrate datatables or custom business objects, and then passing these complete objects back to the caller via webservice would go a long way to help build an SOA based enterprise.  Developers could finally get objects out of the DB rather than untyped result sets. Just a thought...

 

-M




Post #179208
Posted Monday, May 2, 2005 8:29 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

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

Given that I develop currently in SQL Server (over 9 years now) including its predecessor Sybase and even spent a couple years on PL/SQL.  I am well aware of what TSQL is and is not. 

That said, my comparisons are NOT language specific, but historical.  People rooted in the belief that TSQL will stay around IMO are using the same mentality used by COBOL programmers a decade ago.  COBOL fell fast when new tools came on the scene and I predict that TSQL will do the same.  It will go slow at first, but then the conversion from an older not so well built language like TSQL to a modern language will happen quickly. 

I loath COBOL (save for the evaluate statement) as a language as it was restrictive and limited just like TSQL.  If you needed to do something out of the box, you had to take the long way around to solve it.  CLR will open up the database.  In some cases this will be bad, but for the most part it will be a wonderful addition to a developers arsenal.

Personally, I know many DBAs and all are looking forward to ditching TSQL.  It has its place, but in truth when trying to do more delicate coding it is a pain in the rear.  Personally, I welcome the flexibility and power that a programming language brings to the SQL architecture rather than fear it.




Post #179212
Posted Monday, May 2, 2005 8:33 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 5:38 PM
Points: 31,368, Visits: 15,834
I'd agree that MySQL and others will start to integrate other languages into the RDBMS engines, but I don't think SQL will die. For what it can be used for, manipulating large sets of data, it doesn't appear that any of the OOP or procedural languages to as clean a job. Personally I like T-SQL for set based things, hate it for stringmanipulation, complex business logic, etc.

Somethings are better suited for the db, some are not. The CLR in the database is not a great idea. I understand the function writing, and that could really help in analysis or string type functions, but I'm not sold that writing general ad-hoc stored procedures is a good idea. The database is a limited resource. Better to move these things out to other boxes that aren't limited.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #179213
Posted Monday, May 2, 2005 8:50 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 14, 2008 6:43 PM
Points: 14, Visits: 3
I agree queries will still be run, but that is what they will be... queries.  The logic I think will eventually (it will take years) be in a more progressive language such as C#.


Post #179219
Posted Monday, May 2, 2005 10:07 AM
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
What caught my attention in the article was the issue of where to place the business logic layer. This is somehting where I think Microsoft has misled their community by focusing on three layers in the n-tier approach, the name implies how we should look at it but way to often the focus has been an absolute three.

The way I see it shops are going to go to their strength and create busienss layers where they make the most sense. The important idea is to create clear boundaries between the layers and rules for how the layers interact. If that means the dataset is cleand up before handing it off to the developers then so be it.




Everett Wilson
ewilson10@yahoo.com
Post #179232
Posted Monday, May 2, 2005 10:35 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

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

I have worked on several n-tier apps and the logic has always ended up where it makes the most sense.  Everyone tries to keep it in the middle-tier, but often for performance reasons it ends up in a stored procedure or on the client side before it is posted to the server especially when running apps over the internet where latency is an issue.

I would guess at this point MS would rather you just shove it in the DB.  Mainly because once it is there, you are tied to SQL Server.  As a developer, middle tier is usually best because it gives you long term flexibility.  However, design needs often push logic into places where we would rather they not be. 

I wouldn't be suprised in the future if business objects move around between systems (database, app servers, etc) based on performance and other indicators.  Will a developer really care where something runs when he accesses the XYZ object on a server from the client.  It would be nice to setup a machine or machines as a business cluster and let the OS figure out the most optimal place to run business objects.  Sure would give a lot more power to grid computing.  Have a performance problem server side?  Slap another server in, run a quick config to add it to the grid and database/business tier performance would go up universally.  It never is that easy, but who knows what the future will bring.




Post #179239
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse