Hacker News Reader

Comment by jrockway | Hacker News Reader

There's a reason that Java is not called "NoPHP". While technically true, it's just not very descriptive or meaningful.

A better analogy IMO is Python, Ruby et al calling themselves "dynamic languages" to distinguish themselves from the popular static languages of the time.

But they called themselves dynamic, not "NoC++" or "NoJava". That is, it was described by its intrinsic properties instead of as not "a specific instance of a something that implements what they don't like."

SQL is a way to interact with a relational database, but it is not itself a database. But "NoRDBMS" still isn't as good as saying what the technology is - there are an infinite number of things that are not relational databases.

The point of the NoSQL movement is not to advocate a specific technology (e.g. Java, CouchDB, etc), but merely to encourage people to consider NoSQL databases for the 5-10% of cases when SQL works poorly.

Then it would probably be more useful to focus on the problems that the specific databases solve, rather than talking about them collectively in such a general manner. It makes it hard to focus on their strengths.

I would love to read a really detailed comparison of CouchDB (for example) to RDBMSs for common uses, by someone who thoroughly understands the relational model and is very familiar with (say) Postgres or Oracle. I like Postgres and SQLite, but I'm curious about CouchDB - it's a different kind of tool, and it probably has several complementary use cases.

NoSQL solves many of the problems that SQL has (with tradoffs, of course). The big ones:

Performance: Key value stores are fast. You lose features like queries by anything other than index and/or ACID guarantees. (Tokyo Cabinet or Redis).

Data structures: storing non-flat data (trees, graphs) in a SQL database == FAIL. Building a DB around a non-flat data structure lets you avoid doing O(N) queries to traverse a structure. (See Neo4j for graphs or CouchDB/Mongo for trees).

Yes, thank you. Details about the trade-offs involved would be better. My objection is that collectively dealing with them as "the NoSQL databases" tends to obscure that e.g. the key/value stores have very different design and performance trade-offs than CouchDB does, for example. Redis runs entirely in memory, which has big implications for both speed and data set size. And so on.

I should have said "trade-offs" to begin with...that was the heart of what I was getting at when I said "strengths".

"Data structures: storing non-flat data (trees, graphs) in a SQL database == FAIL"

Can you expand on this a bit? Or is this another MySQL-ism? Databases I use work just fine for trees/graphs.

Some methods of storing trees that I've seen:

You can store a tree using foreign keys for the children, but traversing the tree to level m requires m joins. Finding children at an arbitrary level requires O(tree depth) queries.

You can use preorder tree traversal which consists of mapping nodes to pairs of numbers representing intervals on the real line. Then "x is descended from y" is equivalent to "x's interval is contained in y's interval", and this at least lets you find the children of x. Going up a tree is harder. Inserting into the tree is tricky as well.

Another hack is to store on each node a string containing it's ancestors. I.e., "/2/4/27/35" indicates a node is descended can be reached from the root (node 2) by following the path 2->4->27->35. Then the regex search "2/4/27/35/.*" finds all children of node 35. This one is utter fail.

However, I freely admit I'm not a database expert. Is there some non-ugly solution I'm unaware of?

Reply on news.ycombinator.com