Developers still need database skills
Rant here. First off, I’m going to be talking about DBAs. And by DBA, I mean a database developer. Someone who knows relational theory, optimization, and SQL inside out. This is an R&D DBA. There is another type of DBA that mainly deals with uptime and backup strategies. This is an IT DBA, I’m not talking about that one at all.
I was going to talk to some of my fellow developers about a couple of database issues. The response was, “you said the ‘D’ word. Now, we are an NHibernate/Microsoft SQL Server shop (or, Fluent NHibernate), and we rarely have to think about think about database architecture. Heck, up till a month ago I don’t think we had to do any native SQL queries at all. Currently, I don’t think we have any stored procs at all. In my book, all of that is a good thing. You can also chalk one up to Microsoft SQL Server in this one, our system has grown a lot and performance has remained pretty darn stable.
And lets be frank, I love this – most of the time. Linq To NHibernate queries, Fluent NHibernate, and the like all make for a very enjoyable experience for developing against a database. I would say that the vast majority of our querying needs are met with no further issues. I certainly don’t want to go back to a stored proc world.
That said, I don’t like using our ORM as an excuse to not talk about database issues or SQL issues. If you are using a particular data storage technology, it still behooves you to know as much about it as possible. Otherwise, when you get to a point where you need to know about what is going on will be too late. Lets be frank here, no ORM will handle all of you query needs. At best we are talking 90%, sometimes only 80%, for a typical application. At some point you either have to go to the metal, or you end up coding things in a very strange way.
So here is the main point, as long as Relational Databases continue to be the “right answer” for business data storage, you need to learn database theory and SQL. You might not need to know SQL as well as your native C#, Ruby, or other main language. But that is not an excuse for not being comfortable with left outer joins, third normal form, and indexing.