3 ms·

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

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.

yummyfajitas 17y ago
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).
- silentbicycle 17y ago
  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".
- logicalmind 17y ago
  "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.
  - yummyfajitas 17y ago
    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?

yummyfajitas 17y ago

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).

silentbicycle 17y ago
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".
logicalmind 17y ago
"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.
- yummyfajitas 17y ago
  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?