My advice: avoid MySQL like the plague. PgSQL and SQLite is all you ever need and all you ever want.
This is a big early career mistake. I've seen experienced developers use NoSql in a project where Sql is clearly a great fit, then waste lots of manpower to emulate things you get with Sql for free.
Of course one's career can fall into a success path that never depends on SQL, but not learning SQL deeply is not a safe bet.
I've seen things you wouldn't believe. Random deadlocks in multi-billion transaction reporting systems. Atomic transactions split into multiple commits in banking applications. Copying rows between tables instead of setting a flag on a row. All because highly paid programmers are scared of RDBs.
Really? That's not my experience over the last thirty years of programming. As soon as relational databases became something that everyone could use we all jumped in And not just programmers either, a lot of people who never wrote a line of code in their lives became adept at writing SQL in order to get around limitations in ERP systems for instance.
Is this problem something that afflicts only younger programmers?
Yeah it is, until you're trying to manually create and maintain relations between documents in different schemas owned by different microservices.
The SQL course has almost no love by the students but so far it has been the most useful and interesting to me.
I was able to create some complex views (couldn't understand how to make materialized views in MySQL), but they were still very slow.
I decided to copy most of this forum DB to DuckDB (with Knime now, until I know better), and optimization with DuckDB seems pointless. It's very, very fast. Less energy usage for my brain, and less time waiting. That's a win for me.
My current dataset is about 40GB, so It's not HUGE, and sure people here in HN would laugh at my "complex" views, but so far I've reduced all my concerns from optimizing to how to download the data I need without causing problems to the server.