21–30 of 47 posts
Earlier quoted context omitted.
NoSQL refers to non-relational DBMSes, not a literal lack of SQL... QUEL is, if anything, closer to relational algebra than SQL is. https://en.wikipedia.org/wiki/QUEL_query_languages QUEL is a better language (more consistent), and SQL won not on technical grounds, but because Larry Ellison is a better salesman than Michael Stonebraker.
Yeah, I wondered if anyone was going to be pedantic about that. ;)
Earlier quoted context omitted.
NoSQL refers to non-relational DBMSes, not a literal lack of SQL... QUEL is, if anything, closer to relational algebra than SQL is. https://en.wikipedia.org/wiki/QUEL_query_languages QUEL is a better language (more consistent), and SQL won not on technical grounds, but because Larry Ellison is a better salesman than Michael Stonebraker.
Yeah, I wondered if anyone was going to be pedantic about that. ;)
Your post is wholly based on time travel (~"nosql predates sql") and introduces a completely alternative evolution of database design in which quel never happened and we go "full circle" to the nosql-that-was-prior-to-sql.
Earlier quoted context omitted.
There isn't a lot of competition in the "free/libre database" market though. The only serious players are Jena/Fuseki (an RDF store) and Janus (a graph store).
There's also https://github.com/postgraphql/postgraphql
This is awesome. So many of the problems in legacy projects that I've had to deal with have been from trying to shoehorn a graph business process into a tree database.
A "graph business process" is borderline content free. All business processes can be expressed by graphs. What is a graph? A dynamic data structure. That is it. So what is a "tree database"? A graph database with a bias for a specific ordering of its nodes. Does that make a tree database a query result (path traversal) in a graph database? The confusion of it all. So imho one uses a "graph database" when (a) the doma…
Wondering if anyone has experience with it... there's a lot of competition in graph database market, curious to see if this is worth investing time in.
There isn't a lot of competition in the "free/libre database" market though. The only serious players are Jena/Fuseki (an RDF store) and Janus (a graph store).
Earlier quoted context omitted.
Yeah, I wondered if anyone was going to be pedantic about that. ;)
"Pedantic"? Your post is wholly based on time travel (~"nosql predates sql") and introduces a completely alternative evolution of database design in which quel never happened and we go "full circle" to the nosql-that-was-prior-to-sql.
Which is not to say that the poster wasn't wrong about their claim, but it's not invalid to make said claim in casual English in the particular way you're implying.
Though, also, in the more general case, "NoSQL" databases did certainly exist at the time Postgres was conceived (Postgres just wasn't one of them.) Navigational databases like IBM IMS were what we'd call "a NoSQL database" if they were conceived today.
Earlier quoted context omitted.
"Pedantic"? Your post is wholly based on time travel (~"nosql predates sql") and introduces a completely alternative evolution of database design in which quel never happened and we go "full circle" to the nosql-that-was-prior-to-sql.
I don't think the parent claimed that NoSQL existed at the time; just that Postgres was a NoSQL database as we understand the term today . Like describing a wandering swordsman in ancient China as a "knight-errant", even if knights themselves as legally-warranted weapon-carriers didn't yet exist. Which is not to say that the poster wasn't wrong about their claim, but it's not invalid to make said claim in casual Engl…
I've been following this for a few months. It looks neat but too new to entrust to any major project in my opinion. Also seems too new to put together and meaningful performance comparison since it still seems they're finding frequent improvements. I really wished this could have been distributed as an extension rather than a totally separate Postgres package. It is much easier to play with extensions... I read somew…
But I don't know why a performance comparison would not be meaningful at this point? I mean, it may get obsolete soon, but it's the only way to guide optimizations efforts - you do a test, decide what makes most sense to improve (cost/benefit) and then you fix it. Then you do the test again.
I'm sure Bitnine developers do such benchmarks as part of development, but perhaps they decided not to publish that at this point. That's perfectly understandable - development benchmarks are one thing, but publishing the results requires much more care. Particularly when it's a comparison with other products.
But hey, there's nothing simpler than doing a quick benchmark on your own - after all, the best benchmark is one modeling your particular use case.
Earlier quoted context omitted.
There isn't a lot of competition in the "free/libre database" market though. The only serious players are Jena/Fuseki (an RDF store) and Janus (a graph store).
There's also https://github.com/postgraphql/postgraphql