SQL Server 2005: What's New? - CLR Integration
(Page 5 of 5 )
The last and most important change to SQL Server is the integration of the .NET CLR into the database server query environment. According to Microsoft, "Using common language runtime (CLR) integration, you can code your stored procedures, functions, and triggers in the .NET Framework language of your choice." I suppose this is great for .NET programmers, but what about the rest of the world using SQL Server with Java, PHP, COBOL, ADA, etc?
How about this line: "Many tasks that were awkward or difficult to perform in Transact-SQL can be better accomplished by using managed code…" The idea here is that developers can perform complex processing on their data before the next application tier ever sees it, but I must ask - what's the point? Those tasks are not database tasks! SQL is for data management and retrieval, not output formatting, mathematical computations, graphics or list processing. Why keep piling on the features? Why dilute SQL with extension upon extension until you have this big mess that does nothing well? Please humor me while I digress.
Author's Opinionated Note:
Apparently Microsoft is encouraging its users to convert SQL Server 2005 into a crude file system and avoid declarative programming entirely. Any programmer worth a week's pay knows that not every tool is suited to every task. Sure, you use a paring knife to skin a pear - but do you use it to hunt a wild boar? Hell no! SQL exists for a reason - to manage data. That's it! Why are we adding XML datatypes with XQuery support to the RDBMS when it's a middleware task, not a database task? Why are we writing triggers in application layer code in the RDBMS? Integrating the CLR with SQL Server is tantamount to the destruction of tiered architecture. Kiss it goodbye, people. Let's write all of our data management code in the database - we'll process it, format it, everything - in the database - that is, the store of data - and then our application will simply print it to the screen. Or maybe we will mix it up and do some tasks in the RDBMS and some in the application, or some code in the RDBMS in .NET and other in TSQL. There is literally zero benefit to this sort of thing. TSQL is bad enough without XML and CLR integration - it's proprietary to the point that migration to another RDBMS is not possible and it encourages non-standards compliant SQL. So for the one or two of you out there working in an environment that only runs .NET and SQL Server on Windows - and will never change or expand - this is great, I guess. For the rest of the world this is just plain stupid. Recite it with me: I will not put application code in my database. I will not put application code in my database. I will not put application code in my database. I'll hold you to it. |
To sum it up, SQL Server 2005 offers some great new BI tools and some really nifty enhancements to the Transact SQL language, but overall SQL Server 2005 seems to be a major step backward in terms of application and RDBMS development. Microsoft is taking a proprietary system and making it proprietary to the point that it doesn't even have an identity anymore. This is a perfect case of Microsoft trying to be everything to everyone and trying to apply one tool to every problem - and that, people, is not the way to run a database.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 32 
