| The note about composability annoys me. Does it have composability akin to functional programming languages? No. But SQL isn't a functional programming language. Never has been. It's the world's most popular 4th generation language. (Most popular high level languages are 3rd gen in case a reader was wondering.) With the lens that SQL is a DSL for set theory and set transformation (which it is), composability takes the form of views, temp tables, and CTEs. Not what you're looking for? That's fine. But they 100% make SQL composable. I take issue with saying it's inconsistent as well. Are there warts? Sure! Like any language. But fundamentally inconsistent from the lens of DSL for set theory and transformation? No. Folks keep trying to make relational system access like their favorite programming language, and it's not going to happen. Are folks' favorite general purpose programming languages 4th gen languages with an emphasis on set theory and transformation? No? Then stop trying to shoe horn it on! It only leads to frustration. Embrace the set theory and 90% of SQL's issues don't register as issues anymore. As for NoSQL like MongoDB as a Postgres extension, that's what jsonb and its related operators and functions are for. Seriously. to_jsonb(…) and jsonb_populate_recordset(…) are seriously under-appreciated. They're like rocket fuel for JSON processing. Of course you're also welcome to keep a jsonb column lying around to keep things "schemaless", but experience has shown that defining your data (with types) rather than allowing free-form blobs in your database is better in the long term. You obviously see this already by your trust statement with regard to coworkers. "Better" meaning more performant and easier to maintain. Just like thinking "functionally" takes training and practice to grok when you've been object-oriented all your life, that "set theory" takes training and practice as well. And it's so worth it. Feels like a goddamn superpower sometimes. |