+44 (0)208 241 1762Build, Comparison and Synchronization from Source Control = Database change management for SQL Server
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?
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.
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...
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.
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.