You just said to use the right tool for the right job, a few comments above.
Everything you are saying here sounds like a job for something other than a relational database.
I would shit a brick and beat any database developer with it that introduced the idea of a class as a primitive. Fuck that happy horse shit.
Also, graphs? Really?
You're looking for an ORM and blaming SQL for not being that.
There is no common database pattern that creates one table as a subset of another table. RDBMS is, by nature and design, not something you modify in that way on the fly. If you want that kind of object oriented functionality, push your data into a cache layer or column store or KV.
You said it yourself. Use the right tool for the right job. Nothing you've said makes even remotely any sense as a criticism of T-SQL or SQL in general. That's not the right tool for what you're talking about.
Not that a class needs to be a primitive, but that patterns like inheritance should be reusable in some way through templating or the like.
And the inability to pull down a graph as a single operation is the perfect example of sql's limitations.
Relational model is great right? Right. So why throw it out the window and give me a glorified excel spreadsheet as a result set? If I want to pull down a thing and it's related subthings in a single operation, I have to join which is wasteful in that case. This actualy hamstrings ORMs.
I understand relational databases just fine. I still have no interest in the Stockholm syndrome of defending a platform where a = a can evaluate to something equivalent to False, regardless of the theoretical underpinnings of three-valued logic.
There are so many pain points in SQL that are defended because theory.
Everything you are saying here sounds like a job for something other than a relational database.
I would shit a brick and beat any database developer with it that introduced the idea of a class as a primitive. Fuck that happy horse shit.
Also, graphs? Really?
You're looking for an ORM and blaming SQL for not being that.
There is no common database pattern that creates one table as a subset of another table. RDBMS is, by nature and design, not something you modify in that way on the fly. If you want that kind of object oriented functionality, push your data into a cache layer or column store or KV.
You said it yourself. Use the right tool for the right job. Nothing you've said makes even remotely any sense as a criticism of T-SQL or SQL in general. That's not the right tool for what you're talking about.