[sjwright]

But assembler is the wrong analogy for SQL. SQL isn't a lower level version of procedural code, it's a domain specific language.

When you write a technical paper in English, you switch to math equations when appropriate. Math isn't assembly language, its the correct language. It's the native language.

Yes, you can always describe your equations with English prose—and if you're doing simple addition and subtraction, it's probably nicer to write that in English. But once you want to do anything remotely complex, writing it as a math equation is more terse and less ambiguous.

[icebraining]

> Yes, you can always describe your equations with English prose—and if you're doing simple addition and subtraction, it's probably nicer to write that in English. But once you want to do anything remotely complex, writing it as a math equation is more terse and less ambiguous.

Right! But 99% of the time, I do not want to do something complex - I just want to load a few rows based on simple search parameters, and save a changed values (which may involve heavy data processing, but not relational). Hence only using SQL rarely, and therefore getting rusty.

[sjwright]

If you're only doing basic CRUD operations, then fair enough.

That said, based on my experience analysing applications, "loading a few rows" to perform "heavy data processing" and then "save a changed value" smells suspiciously like "the entire task can be rewritten as a single, moderate complexity query and the data never even had to leave the database server."

I'm not saying that's the case in your own generic hypothetical, as there are indeed forms of business logic and advanced manipulations that exceed the scope of a database server. But you might be amazed at what you can do within the SQL language. For example if you aren't intimately familiar with window functions like DENSE_RANK() then do yourself a favour and learn about those—and then contemplate how you could use them within a subquery joined to a table that you're updating.

[icebraining]

Well, my current "heavy data processing" is generating a 3D render from some metadata stored in the database. Postgres is amazing, but I don't think it can do that yet :)

My experience over my career has been this: there's CRUD, lots of IO, and a bunch of data processing that just needs specialized software (image, video, weather simulation, etc). I try to offload what I can to the database - and yeah, I know about window functions - but other than for the occasional report, it just doesn't move the needle.

[sjwright]

Fair enough. It looks like we use databases in rather different ways.