The fact that you'd need to keep this structure in SQL and make sure it's consistent and updated kinda proves my point.
It's also not really relevant to my example, which involves a single level parent-child relationship of completely different models (posts and tags).
"The planet is fine. The people are fucked."
SQL blows for hierarchical data though.
Want to fetch a page of posts AND their tags in normalized SQL? Either do a left join and repeat all the post values for every tag or do two round-trip queries and manually join them in code.
If you have the tags in a JSON blob on the post object, you just fetch and decide that.
I rarely get calendar invites - much less ones that I have to respond to - to my personal Email account. I do on my work email, but I don't plan on self hosting that anytime soon.
So as someone who recently switched to proton before this BS, what's good to switch to?
Damn why does all the software I want to use end up being developed by bigoted assholes. First nix now this.
They're still rambling about Hilary; they'll still ramble about Biden.
Deep fried mozzarella
That's quite the turd(le) they dropped
Fireworks are art. Art isn't inherently wasteful.
VVVVVV is awesome so it's cool
My point is that SQL works with and returns data as a flat table, which is ill fitting for most websites, which involve many parent-child object relationships. It requires extra queries to fetch one-to-many relationships and postprocessing of the result set to match the parents to the children.
I'm just sad that in the decades that SQL has been around, there hasn't been anything else to replace it. Most NoSQL databases throw out the good (ACID, transactions, indexes) with the bad.