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.
One very good reason (and often avoided like the plague) for maintaining decent DB skills is reporting. Even with things like summary screens within an application guarded by an ORM, a poorly structured RDB set up by inexperienced developers, or developers that just don’t give a crap about indexes, normalization/denormalization, etc. will net you some really poorly performing, and inflexible kludge.
I agree with you 100%! A long time ago, Joel Spolsky wrote about abstractions and how they seem to draw people away from having to be knowledgeable about the underlying technologies they are abstracting. An ORM is an abstraction to communicating with the underlying database engine. I have had a long time fear that ORMs would lead to less effective business application developers.
In my book, if you are developing business applications, there is no excuse for not having to know about the database that your application is built on. Not having knowledge about it, could lead to serious performance and locking issues.
Bottom line: ORMs are great – but not a reason to not have a knowledge of the database it is abstracting.
While, I definitely agree with this post and the comments, I’ll play the devil’s advocate just a bit here and say that there must be a balance.
It is good to have a basic understanding of the abstraction in order to use it better and to be able to handle cases when the abstraction is removed, but part of the point of an abstraction is to make it so you don’t think about what is below it, hence the name.
I guess I could parallel it to virtual machines, or C# on top of MSIL or even MSIL on top of assembler code. You can’t know all that stuff, and it wouldn’t benefit you to do so. Hopefully we will get to the point where you don’t need to know about a database, because we just think store data, get data.
But, because we are not there yet. I agree with you Chris. At this point in time all developers should know SQL. It just makes sense.
It’s really true, a good developer must know something more about DB for sake of performance. Many applications acts very inefficiently just because of poor DB knowledge of application developers.
It would be even better if developers would know when not to use a relational database. They haven’t been the right answer for most projects since the introduction of Gemstone and Prevayler.
@Stephan, I would agree with that as well, but…it often is not the developer who gets to make that decision. There are CTOs, and programming managers, and business managers, plus a bunch of existing software to “influence” those decisions. When your application runs in isolation, no big deal. Otherwise you may not be so lucky.