I’m learning SQL at the moment and I’ve read that joins and subqueries can potentially be performance destroyers. I (somewhat) know the theory about algorithmic complexity in procedural programming languages and try to be mindful of that when programming, but I don’t know how expensive different SQL queries can be. I’m deciding whether I should invest time in learning about SQL performance or just notice it when my queries run slow. The base question for me then is: is premature optimization for SQL as evil as it is for procedural languages?
As added information, I work in an environment where, most of the time, high performance is not an issue and the biggest tables I have to work with have some 150k rows.
Here’s the Donald Knuth quote I refer to when saying “evil”:
We should forget about small
efficiencies, say about 97% of the
time: premature optimization is the
root of all evil. Yet we should not
pass up our opportunities in that
critical 3%.
I would say that some general notions about performance are a must-have : it’ll prevent you from writing really bad queries that can hurt your application (Even if you don’t have millions of rows in your tables).
It’ll also help you design your database so it’s more officient-oriented : you’ll have some ideas about where to put indexes, for instance.
But you shouldn’t have performance as a first goal : the first thing is to have an application that works ; and, then, if needed, you’ll optimize it (having some performance notions while developping will help you have an application that’s easier to optimize, though).
Note I would not say that “having notions about performances” is “premature optimization”, as long as you don’t just “optimize”, but just “write correctly” ; I would rather call it good practice that’ll help to write better quality code 😉