Re:Against SQL
by randomdata on Saturday July 10, 2021 @05:50AM
(#27792319)
There was a strong push for "NoSQL" about a decade ago, but it got marred by document databases trying to usurp relational databases around the same time. When people realized they chose the wrong tool for the job (that is, the document database), they were happy to return to their relational databases using SQL. That completely killed any momentum that had been built to replace SQL with different languages.
[ Parent
| on HN ]
I don't think that NoSQL ever was about better query languages for relational databases. It was about making databases faster and easier to use by using simpler data models with fewer guarantees.
Re:Against SQL
by 1337shadow on Saturday July 10, 2021 @06:14AM
(#27792405)
And now that we can query JSON fields in PG we get the best of both world.
I like this (and use it) but it has to be said, the syntax is grim.
Still, I'd rather query JSON in postgres than do joins in mongo.
For now. Next version (currently in beta) will support the usual [] syntax in queries: https://blog.crunchydata.com/blog/better-json-in-postgres-wi...
Same for MSSQL, all XML or JSON Syntax is very… unfun.
The author seems to think that putting structured data in columns is a good idea. That is pretty clearly contrary to the basics of the relational model itself, never mind SQL. In fact it's quite close to how document databases work, so a very NoSQLish proposal overall.
Re:Against SQL
by fauigerzigerk on Saturday July 10, 2021 @07:52AM
(#27792744)
>That is pretty clearly contrary to the basics of the relational model itself
The consensus among relational theorists appears to be that data types can be arbitrarily complex. For instance, C.J Date and Hugh Darwen write the following ([1] page 56):
Third, we remind you that types are not limited to simple things like integers. Indeed, we saw in Chapter 1 that values and variables can be arbitrarily complex—and that is so precisely because the types of those values and variables can be arbitrarily complex. Thus, to paraphrase a remark from that chapter, a type might consist of geometric points, or polygons, or X rays, or XML documents, or fingerprints, or arrays, or stacks, or lists, or relations (and on and on).