Understanding SQL and being able to work with data interactively has made me a better software engineer. This tech is important enough that it should be taught in university/coding camps.
Ditto.
My teacher was hardcore. He was a graybeard who was around before Codd's now famous paper. He worked with some of the old pre-relational hierarchical databases.
We had to take SQL queries, turn them into relational calculus and algebra, turn that into a query plan, then come up with an estimate for the time the query would take to run given various hardware speed numbers and the size of the data.
We had to implement our own (primitive!) database engines, including various join algorithms.
To date it's one of the hardest, yet most rewarding, learning experiences I've had.
That sounds fun. My most intense undergrad class series was one where we soldered together a M68HC11 computer and learned assembly one class, built an OS for it the next, and then turned it into a robot with control software running on our OS-es.
If we had a database course that went that in-depth, I'd've definitely taken it, too.
I was so zealous about normal forms that I complained loudly at one job where they used an old D3 database with multivalue fields. It was so glaring to me because we actually used all hand-rolled SQL instead of an ORM in those days. Years later, after growing less tech-centric and more thoughtful of business needs, I realized that sparingly using multivalue fields was not a hill to die on. :)
Fast forward many years to my first startup in Boston. Google App Engine was new and I wasted precious time trying to figure out how to shoehorn a typical relational data model into the early NoSQL data store available for App Engine at the time. This was just after the financial crisis and I hadn't yet heard the mantra to pick boring technologies, and I learned through sheer pain that unless you really really really need to, don't waste effort by walking away from relational databases. And also, most apps can get by with whatever the ORM does and if there's a performance issue, optimize that one query instead of trying to optimize all your SQL from the beginning. There's a lot I still don't know about pushing heavily complex queries down to the db level, but for expensive problems I'd reach for expensive assistance, because it's worth it (after trying to play with the SQL myself).
I recall one group doing the project login which went much along the lines of what the OP's article touched on. Their code was esseentially
var success = false
var query = SELECT * FROM users
while query.read
{
if query(user) == input_user && query(password) == input_pass
{
success = true
}
}
Yes. They iterated over the entire result (even if first returned result was valid)
Yes. That was "shipped" for the project
No. My complaints notion they should be leveraging the database for all the things they're doing wrong were ignored. It was performant! Look! It logs in instantly! YEah, because there's 8 users on the database for this project, what about when it ""ships"" and there's 100,000? More?
---
My first real job dealing with a database wasn't much better. We were using a MS Access database with no normalized data. Our client's primary transaction data was across a table with 70 some columns, many of which were often duplicated values in some form or utilizing very bad practices. Since joining this company I've sped up queries in almost immeasurable ways and done things my older coworkers initially derided because they couldn't understand the syntax.
TL;DR SQL, for some stupid reason, is still treated as second class to core langauges and it is a god damn shame
Agree so much. And if you've ever seen a real SQL wizard in action, you realise how much can be done with it. Like most of the business logic of a system can be in the database, with an interface that's a set of stored procs/functions. And fast.
The problem of this approach is the tooling and lock-in.
If databases had first-class versioning support for their code objects (which could easily interoperate with git), testing automation, and a parvence of standardization across the industry, then a lot of people would be very happy to work with that model.
But they don't.
I've seen a program rewritten or heavily refactored on top of an existing database more times than I've seen the database swapped on an app that had reached production (which I've seen zero times).
Consequently, I have regard remaining "database agnostic" as having very little worth. If you pick a DB with a bunch of great features that can save you time, improve performance, and improve data integrity—use those features!
Plus, if you find yourself in that rewriting-or-heavily-refactoring job that I've seen a few times, your favorite person in the whole world will be whoever put all those annoying constraints and triggers and such in the DB itself. It'll make the operation far easier and safer.
Postgres-as-a-platform is definitely a new architectural trend, but because of companies like Supabase it's maturing quickly, and there are so many benefits to it when executed properly.
Though I have met DB Admins who insist that the only way of stopping bad data getting into the DB is to have the DB do all the data manipulation, including a lot of what we would now consider business logic