There are many, many fascinating and helpful new features in the upcoming SQL Server 2005 (or if that's too much of a mouthful, TDFKAY = “The DBMS Formerly Known As Yukon”. On second thought that doesn't really help.) I remember for example experiencing a probably improper and immoral thrill when I learned of the existence of a DATE datatype that only holds a date, with no time. YES!
However (proving by the way that I just found out what SHIFT+ENTER does), as .NET developers we know that the thing that really excites us about MSS2005 (erk) is the ability to create user-defined types in our managed language of choice and write stored procedures using managed code.
Where previously data manipulation might be split awkwardly between the database and application code, thereby often creating code dependencies that compromise the ability to use the same database elements from different applications without a lot of copying of code or adding of references, now, because we have access to fully-featured modern languages (and if necessary and allowed, their even more fully-featured libaries) from the database itself, we can keep everything that is er, of the data with the data. Or to put it another way, all the code that is necessary to interact meaningfully with a given piece of data can be put in one place. Yeay encapsulation!
It is quite likely that this will also save the bacon of those who have been using T-SQL as an application programming language and putting *everything* on the database. You all know who you are (and frankly your bacon is undeserving of salvation.)
And yet...I see problems on the horizon.
Imagine going to your friendly neighbourhood DBA with your bright shiny new CLR code and asking to have it installed in the database (that's not quite what's happening but we'll sort out the terminology with time). I see DBAs around the world linking arms in the spirit of brotherhood and joining one another in a rousing chorus of “You're Not Putting *That* On My Server”.
The first hurdle is security: you have a group of people still reeling from the horrors of xp_cmdshell and now you want them to allow you to expose their database to the full glory of a real programming language, with all that that entails. Fortunately the security angle has been addressed quite well as far as I can tell, with the “Safe”, “ExternalAccess” and “Unrestricted” permission sets.
Then we have the issue of the code itself: if someone doesn't know the language, how can they apply standards to it, or assess whether it is conducive to optimal execution plans? Or just avoid being really, really nervous?
I could go on, but I think I'm all ranted out now. My point is that for SQL Server 2005 to avoid ending up as a product with lots of very useful features that nobody ever gets to use, Microsoft need to communicate with DBAs to address not just the cool database stuff (which I think they're doing quite well already), but also to fill them in on the brave new world of managed code, coming to a server near you soon. Database administrators themselves would in my opinion benefit from abandoning any “I don't need to know that programming crap” ideas and getting themselves booked on introductory C# and/or VB.NET courses. Actually, there could well be benefit in putting together “Managed Code For Database Professionals” courses if this has not already been done.
Right, that's it from me for now.