3 ms·
Totally. The problem is that most mix "SQL" the QUERY language, and the RDBMS on top of it. So the problem is how "constrain" the SQL as query language so it n
by mamcx 7y ago
Totally.
The problem is that most mix "SQL" the QUERY language, and the RDBMS on top of it. So the problem is how "constrain" the SQL as query language so it not allow to DROP tables.
So, most app will benefit from:
CLIENT(SQL) -> RDBMS(SQL)
but, as normal is instead:
RDBMS(SQL)
and that is the problem.
So, in typical fashion in our industry, we build a impedance mismatched solution!
CLIENT(GRAPHQL) -> CLIENT(SQL) -> RDBMS(SQL)
yep, more logical.
P.D: And seriously, the SQL guys also are part to blame. Somehow, along the line, the FACT sql is a query lang made for humans/developers have been ignored, and can't make a better version of it. For example, SQL can't be composed except with string mangling.
- iamwil 7y agoReading the original notes for SQL, I remember reading it was designed as a human readable query lang. I think you have to remember the context of the time. At the time (in the 60's), the alternative to SQL was writing your own imperative implementation of a query through a hierarchical database. Kinda like if you had to implement traversal through an XML document every time you had a new query. In some ways, that's what we're doing nowadays writing resolvers with graphql servers. Composition was bolted on later as an afterthought. The requirements we have for a query language is different with a different environment now.