11–20 of 466 posts
Would be nice, but bazillions of lines of SQL at the core of almost every business system make this as likely as “We can do better than five fingers.” The article does nicely illustrate many of the well-known shortcomings of SQL. Chris Date and Hugh Darwen unsuccessfully tried to fix SQL with Tutorial D. Never heard of it? Exactly.
"Has anyone fixed these problems elsewhere?"
Then:
>The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases. Unfortunately, in the pursuit of ditching SQL, the NoSQL approaches also abandoned the relational model and other good parts of RDBMSes.
Yeah that's what I was thinking, they really don't fix the issues listed, just have chosen to solve other problems, but not in a "going to fix SQL" kind of way.
e.g. result = dframe.select(*[f.col(colname).alias(f"{colname}_old") for colname in dframe.columns]).join(other_df, 'joincolumn', type='outer')
and so forth.
But (as I haven't read of their blog posts) I am a bit more reluctant about the whole thing when they describe it as an ORM.
Can we leave the ORM and take the query language and implement this as a Postgres extension?
As I read this I wondered: "Has anyone fixed these problems elsewhere?" Then: >The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases. Unfortunately, in the pursuit of ditching SQL, the NoSQL approaches also abandoned the relational model and other good parts of RDBMSes. Yeah that's what I was thinking, they really don't fix the issues listed, just h…
I'm a little bit young, but isn't this a bit of a revisionist take, by the author?
I thought that Amazon, Google, FB et al moved away from relational databases because the sharding logic they needed to build on top of these databases was approaching the complexity of a RDBMS. They didn't need strong consistency or support for complex queries, on the kind of data they were storing at scale, and so made compromises in those areas while engineering their purpose-built alternatives (Dynamo, BigTable, Cassandra).
It's not that SQL didn't work, but that the persistence layer was too strong and therefore too slow for their very particular needs. It's like comparing a minivan/suv (mysql/postgres) to a drag racer (nosql databases). You don't want to drive your kids to soccer practice in a two-seater with no airbags, and a 5* crash safety rating isn't as important to the pink-slippers as horsepower and 0-60.
Or am I missing something?
Previously https://news.ycombinator.com/item?id=19871051 (428 comments)
I've grown pretty fond of the way Spark SQL queries can be represented with DataFrame operations. There is a more or less 1:1 relationship with SQL, except the commands can be programatically generated and composed. It sure beats stitching together a SQL string when you have a bunch of query clauses that might be optional, or need a generalized way to take 30 result columns, and rename them with a prefix or something…
By reading the queries it generates it's quick to pick up how the SQL works! Another big advantage is that you can always pull the data into R and have a ton of general purpose tools available.
dplyr is aimed at data analysis though, so may be other use-cases for edge db?