[danield9tqh]

Although I agree with most of the author's points I think he underestimates the value of ease of use by programmers. SQL syntax can definitely be daunting to some and difficult to understand complex queries. There is room for improvement in that regard.

[bigiain]

<devil's advocate>Perhaps those programmers should take a little time out of their "learn the latest Javascript framework" budget and spend a little time learning to use SQL properly? Just because a powerful and industry standard tool is "daunting" that's possibly the _worst_ reason to choose something less well suited to the problem...

[paulddraper]

But then I'll be behind in JS, by like 3 frameworks.

[btilly]

Take your favorite complex query. Write code to accomplish the same thing with raw data in whatever format you consider convenient.

You will be AMAZED at how compact SQL actually is by comparison!

[davidgould]

Indeed.

An often overlooked point is that good SQL optimizers generate different versions of queries depending on the current state of the database and the actual parameters to the query. That is, the optimal query plan for finding the sales to "school teachers" is probably different than for "astronauts" and the optimal query plan for reporting on "todays orders" is probably different at the start of the day than late in the afternoon. SQL query planners try to do the right thing with this sort of data variability and generally (but not always!) do a good job. It would take an immense amount of work and insight into the data and all the potential use cases to approach this with custom coded queries.

Before there were relational databases these sorts of access path, query strategy decisions had to be made by developers and were reflected in the schema and physical design of the database. This was inflexible and very labor intensive and it made many kinds of applications and or even routine changes uneconomical.

[btilly]

Oh trust me, I don't overlook that point. I've spent too much time cajoling optimizers into the query plan that I know will work when they think they know better. And I know from painful experience how much more work it is to cajole developers in the same way.

That said, there is little point discussing this subject people who clearly have no experience about how to do what a little bit of SQL does. If you're convinced that manipulating data is easy, you're not going to appreciate that manipulating data efficiently is even more tricky.

[wruza]

The comparison of the code in the article is a little unfair, though. You have to prepare a statement, bind some values to it, and then convert engine-specific data in a loop into your language's representation. Of course DB-modules help with that, but the boilerplate complexity remains.

[btilly]

The boilerplate is manageable. And with the right DB-modules, it practically disappears.

That said, do try to rewrite a moderately complex query without SQL. Pick one with multiple joins, several where conditions, and a group by. You will generally wind up with a fragile program that is many times as big as the equivalent SQL, and is a lot harder to read and maintain.