Who’s Afraid of the Big Bad SQL Statement?
I had a rather interesting conversation with Chris Birmele of Microsoft at the recent Heroes Happen launch event here in Perth. We were talking about which version of Visual Studio 2008 Team Suite would be the most appropriate for development teams in Perth. I was lamenting that Database Edition had some killer features for us, such as source control for the DB, but it would still be nice to have the class diagramming feature from Development Edition.
Chris was explaining that the Database Edition of VSTS was meant to be used by the DBAs on our projects, so the rest of the guys in the team could just use Development Edition.
The thing is, I've never seen or heard of anyone in Perth running a .Net development project with a dedicated, T/SQL cutting DBA. Any SQL work is almost always done by the same guys doing the C#/VB.Net code.
Perhaps it's a Perth thing. Over here, DBA seems to mean "makes sure the nightly backup runs" rather than "writes stored procedures all day and fixes indexes". They tend to work for infrastructure companies and aren't involved in designing databases, doing performance tuning or anything like that. We don't really have guys that just specialise in T/SQL for applications. Maybe it's the size of our projects, or just a general lack of demand for someone who cuts SQL code all day. I have no idea.
The number of people who know about things such as proper normalisation, indexing and techniques for maintaining referental integrity is dropping. If you look at the Tiobe Index you'll notice that PL/SQL is only number 13 in the list (remember that this will include Oracle Forms etc), while T/SQL is only number 29. Those figures don't seem all that impressive when compared to Java (number 1) and C# (number 8), the two languages of choice for enterprise application development. Perhaps the popularity of ORM tools such as NHibernate has something to do with it? Regardless, it's getting harder and harder to hire people with good SQL skills, let alone people with good SQL skills AND good .Net skills such as those needed by a large number of teams here in Perth.
This means that any move away from SQL by the general developer population hits us where it hurts. We still need our C# programmers to fix database performance problems. We still need them to do data migration. We still need them to do database design. We still need them to write reports. We still need them to do most of the database related activities that are required when developing any enterprise application.
So by all means keep using Ibatis, NHibernate or whatever ORM you prefer, but please don't be afraid of, or forget about, SQL. It doesn't bite, and if you're in a town like Perth then chances are you're going to need to know quite a bit about it sooner or later. Maybe not today, maybe not tomorrow, but someday, as soon as there's a performance problem or data integrity issue on your project, you're going to have to knuckle down and bust some SQL related moves.
