4 ms·

It's just a marketing/catchy term for the trend to 'next-generation' (read: 'different') database engines. Since there is (in almost all cases) no SQL (the lang

It's just a marketing/catchy term for the trend to 'next-generation' (read: 'different') database engines. Since there is (in almost all cases) no SQL (the language) involved, it is a pretty appropriate name.

jrockway 17y ago
There's a reason that Java is not called "NoPHP". While technically true, it's just not very descriptive or meaningful.
- jbellis 17y ago
  A better analogy IMO is Python, Ruby et al calling themselves "dynamic languages" to distinguish themselves from the popular static languages of the time.
  - scott_s 17y ago
    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.
- yummyfajitas 17y ago
  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.
  - silentbicycle 17y ago
    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?
deleted 17y ago
[deleted]

jrockway 17y ago

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

jbellis 17y ago
A better analogy IMO is Python, Ruby et al calling themselves "dynamic languages" to distinguish themselves from the popular static languages of the time.
- scott_s 17y ago
  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.
yummyfajitas 17y ago
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.
- silentbicycle 17y ago
  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?

deleted 17y ago

[deleted]