Comment by madhadron
7 years ago
This is the wrong direction.
Let's get the history in place first. The relational calculus set up a set of operators. That's what Codd worked with. It was combined with a natural language project at IBM which gave us the vaguely English like syntax of SQL.
> In EdgeDB, the data schema is formulated in a way that is much closer to the contemporary application data model. ...Unlike SQL, EdgeQL can easily extract arbitrary data trees.
This is a reinvention of the the hierarchical database, one of the architectures that was abandoned when the relational database came along. This was all fought out on a large scale in the 1980's.
The fundamental idea that you have a highly structured data tree is what the relational model threw away. "Data Oriented Design"[^1] does a pretty good job of explaining why, but roughly: we're accustomed to programming where we have an object/entity/value that represents a conceptual "thing" in our discourse. We compose things into other things, subtype things, and otherwise deal in things. And this turns out to be a disaster when lots of people need to extend and reuse hunks of the same database. If you give up on things as first class parts of your data model, and only talk about relations among attributes, a lot of those problems go away.
If you want to improve SQL, look at going back to the relational calculus without the natural language veneer. There have been a number of systems that tried that, though none have gotten real world traction. I'm also blanking on their names at the moment, so if someone who's memory is working better can help me, I would appreciate it.
> This is a reinvention of the the hierarchical database
It's not. Just because data can be fetched as a set of "tree-like" things does not make the model hierarchical in any way. But it makes lots of practical use cases easier.
> The fundamental idea that you have a highly structured data tree is what the relational model threw away.
And then ORMs came and reinstated the status quo. Truth is, many applications actually benefit from a highly structured data graph. That said, you don't have to use the "highly structured" bits of EdgeDB, it's perfectly fine if all your types are simple tuples.
> We compose things into other things, subtype things, and otherwise deal in things. And this turns out to be a disaster when lots of people need to extend and reuse hunks of the same database.
I would be very interested in reading about this. Do you have any references? Most cases of "disaster" in my experience had to do with extremely poorly defined and documented schemas that had barely any relation to the actual business model.