Why You Should Understand Databases

In recent years I have seen developers distance themselves from databases more and more for various reasons. The two most common reasons seem to be

  • Business logic should not be split between the database and the application, it should all be stored in the application code. So stored procedures and functions are now an anti-pattern.
  • The ORM (like Entity Framework, Hibernate, ActiveRecord etc) handles the details of SQL and also data migrations. ORMs provide better developer productivity so writing SQL by hand is an anti-pattern.

Regarding the business logic I think it is correct as a general rule and also I agree that ORMs when understood by the developer does greatly increase productivity.

But not understanding how your database works comes at a cost - your application will work great until it doesn't... because

  • you're hammering your database with inefficient queries which in turn is causing your application to run slow, experience timeouts and deadlocks.
  • you're understanding of how things like JOIN, LEFT JOIN work is inadequate and you treat database queries like you do Linq-to-Objects and the data your application works with is wrong and you don't even know.

My basic argument is this. The data is the most important thing in your business. You lose your application code, well you code theoretically rebuild it in a heroic effort to restore basic services but if you lose your data then you're finished. Time to close that laptop and all go home.

Databases store the lifeblood of your business - they are the key component around which all your applications orbit. Just look at how much money your business is willing to spend on SQL Server or Oracle licenses.

So why do so many developers know little to nothing about their databases? It is just plain foolish and naive. 

Understand your database technology! Spend time taking that knowledge further and further just like you do with application centric tech. Start with understanding indexes (clustered and non-clustered) and SQL language concepts and see where it takes you. Don't be ignorant of the most important component in your application architecture.