Comment by CaptainZapp

Yes you can make some lovecraftian horrors if you really want to, but SQL is one of those things where just a little bit of knowledge goes a long way.

I agree. At the same time a little bit of knowledge is incredibly dangerous.

That query, which worked so brilliantly on the test system during devlopment, suddenly grinds all of production to a halt.

The basic problem is that indexing and other physical performance boosters were not really rerquired when those queries were tested with 3'000 customers.

Being set-based that's quite different when you suddenly deal with 30'000'000 customers and a number of joins, which may not be supported by indexes, since that was never obvious in development.

That said: I'm not arguing against SQL. It's a great language for its purpose. What I do argue for is to have an SQL domain expert and an expert on how it phyisically maps to the underlying database engine for more complex projects.

Such a resource can be immensly valuable in assisting application developers to avoid major mistakes when they deal with the underlying database.

Edit: A couple of issues, which actually negated my argument upon reread