5 ms·

First off I find the NoSQL term in itself very strange. How can you say anything intelligent about "everything that is not using SQL as a query language"? Its l

by bni 15y ago

First off I find the NoSQL term in itself very strange. How can you say anything intelligent about "everything that is not using SQL as a query language"? Its like talking about NoJava, instead of talking about Ruby. Props for a well written article with lots of nice graphs but I dont agree with much of its content. A few examples: "software applications are not so often interested in in-database aggregation" In my experience this is what 99% of business support apps are doing. Doing this aggregation in procedural application code will only give you more code to maintain and more bugs. "joins are often handled at design time as opposed to relational model where joins are handled at query execution time" Im glad you know beforehand about your changing requirements over the next 10 years and can "design" your joins for every eventuality right now. It feels like the exact oppisite of agile. I also agree with the very insightful comment by Voice in the wind (comment #4 below the article)

Maro 15y ago
"software applications are not so often interested in in-database aggregation" Applications that used to be desktops apps are now moving to the web, and these "cloud applications" are prime use-cases for NoSQL. Apps like Gmail, Google Docs, Dropbox are cases where a NoSQL might be a better fit than SQL, the same way Word.exe doesn't use SQL internally, instead it uses linked lists and hashmaps [1]. "In my experience this is what 99% of business support apps are doing." Business apps are the original, killer use-case for SQL, and here NoSQL makes less sense, I agree. [1] Some apps like Firefox started using SQLite for local storage, a technical decision I don't agree with.
- batista 15y ago
  Applications that used to be desktops apps are now moving to the web, and these "cloud applications" are prime use-cases for NoSQL. Apps like Gmail, Google Docs, Dropbox are cases where a NoSQL might be a better fit than SQL I don't see anything in Gmail and Google Docs data usage needs that make NoSQL a better fit for them --only the need to scale with no sharing etc. (OTOH Dropbox might fit the case, they only need some hierarchical store a la filesystem, with versioning). the same way Word.exe doesn't use SQL internally, instead it uses linked lists and hashmaps Yes, but Word.exe internally deals with just ONE document and it's data structures, does not manage metadata for many documents and does not have to provide aggregated info on them. That would be Windows Explorer, that manages many .docs. And that one, MS did have a plan to make more SQL-like.
  - Maro 15y ago
    NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff).
    - batista 15y ago
      NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. Per gmail account, you'd still dump all the mails into one gigantic emails table, either an SQL or a NoSQL one. As for the totality of the gmail accounts, well, you'd use sharding, which is the same whether you use NoSQL or SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff). But a SQL DB can also use the same transparent API for the persistent stuff with their standard Query API. It wouldn't even need to parse the SQL statement, just hash it and compare it. And you could also use a layer that makes it transparent, such as an ORM.
      - Maro 15y ago
        So you'd have one 'emails' table per Inbox, right? So for 1 million users, you'd have 1 million tables, and no SQL database can handle that.
    - mattmanser 15y ago
      Huh, why wouldn't you want those tables? You seem to be confusing the need to scale with how you would design the system. Somewhere I worked before we used to import 100,000s of a companies email into the project system to display them against the system. They were all in an Emails table which just stored the body, I think there was an email header table and an email contacts table which was relationally linked directly to the Person table. Worked fantastically, used to run an IMAP server off those tables for outlook integration.
batista 15y ago
First off I find the NoSQL term in itself very strange. How can you say anything intelligent about "everything that is not using SQL as a query language"? Its like talking about NoJava, instead of talking about Ruby. Only it's not like that, because SQL is a well defined way of thinking at problems, not just a particular implementation of it. So, NoSQL is like saying NonFunctional. Or NonImperative. Or NoRegister VMs, etc...
- bartonfink 15y ago
  SQL is a language that is not particularly well defined, nor essential to solving problems. What you're referring to as a "well defined way of thinking" is the relational model. There have been relational databases that did not use SQL as their query language, and although they're not widespread, the same points the NoSQL community makes against e.g. Postgres could be made against them.
  - grannyg00se 15y ago
    Like most buzz words, its popularity has overshadowed it's usefulness. I agree that a word to categorize these recently popular non-relational databases would be handy. But nosql is really not accurate. Unless you abandon all attempts to interpret it literally. When I see "nosql" that now tranlates into "that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees". So at least it means something (to me anyway), and it's abstracting quite a mouth full. Much better than "Web2.0" was. That always just translated simply to "ajax with nice UI" for me, but I saw the term used in so many ways that didn't fit that definition.
    - zorked 15y ago
      "that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees" is exactly what the term means. So I guess it works.
      - 15y ago
michaelmior 15y ago
I agree that NoSQL is a strange term, although perhaps not quite for the same reason. I agree with the statement by @batista that SQL in this context is a defined way of thinking about problems. But NoACID seems much more appropriate especially as many "NoSQL" systems get SQL interfaces stuck on top.

by bni 15y ago

Maro 15y ago

"software applications are not so often interested in in-database aggregation" Applications that used to be desktops apps are now moving to the web, and these "cloud applications" are prime use-cases for NoSQL. Apps like Gmail, Google Docs, Dropbox are cases where a NoSQL might be a better fit than SQL, the same way Word.exe doesn't use SQL internally, instead it uses linked lists and hashmaps [1]. "In my experience this is what 99% of business support apps are doing." Business apps are the original, killer use-case for SQL, and here NoSQL makes less sense, I agree. [1] Some apps like Firefox started using SQLite for local storage, a technical decision I don't agree with.

batista 15y ago
Applications that used to be desktops apps are now moving to the web, and these "cloud applications" are prime use-cases for NoSQL. Apps like Gmail, Google Docs, Dropbox are cases where a NoSQL might be a better fit than SQL I don't see anything in Gmail and Google Docs data usage needs that make NoSQL a better fit for them --only the need to scale with no sharing etc. (OTOH Dropbox might fit the case, they only need some hierarchical store a la filesystem, with versioning). the same way Word.exe doesn't use SQL internally, instead it uses linked lists and hashmaps Yes, but Word.exe internally deals with just ONE document and it's data structures, does not manage metadata for many documents and does not have to provide aggregated info on them. That would be Windows Explorer, that manages many .docs. And that one, MS did have a plan to make more SQL-like.
- Maro 15y ago
  NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff).
  - batista 15y ago
    NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. Per gmail account, you'd still dump all the mails into one gigantic emails table, either an SQL or a NoSQL one. As for the totality of the gmail accounts, well, you'd use sharding, which is the same whether you use NoSQL or SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff). But a SQL DB can also use the same transparent API for the persistent stuff with their standard Query API. It wouldn't even need to parse the SQL statement, just hash it and compare it. And you could also use a layer that makes it transparent, such as an ORM.
    - Maro 15y ago
      So you'd have one 'emails' table per Inbox, right? So for 1 million users, you'd have 1 million tables, and no SQL database can handle that.
  - mattmanser 15y ago
    Huh, why wouldn't you want those tables? You seem to be confusing the need to scale with how you would design the system. Somewhere I worked before we used to import 100,000s of a companies email into the project system to display them against the system. They were all in an Emails table which just stored the body, I think there was an email header table and an email contacts table which was relationally linked directly to the Person table. Worked fantastically, used to run an IMAP server off those tables for outlook integration.

batista 15y ago

First off I find the NoSQL term in itself very strange. How can you say anything intelligent about "everything that is not using SQL as a query language"? Its like talking about NoJava, instead of talking about Ruby. Only it's not like that, because SQL is a well defined way of thinking at problems, not just a particular implementation of it. So, NoSQL is like saying NonFunctional. Or NonImperative. Or NoRegister VMs, etc...

bartonfink 15y ago
SQL is a language that is not particularly well defined, nor essential to solving problems. What you're referring to as a "well defined way of thinking" is the relational model. There have been relational databases that did not use SQL as their query language, and although they're not widespread, the same points the NoSQL community makes against e.g. Postgres could be made against them.
- grannyg00se 15y ago
  Like most buzz words, its popularity has overshadowed it's usefulness. I agree that a word to categorize these recently popular non-relational databases would be handy. But nosql is really not accurate. Unless you abandon all attempts to interpret it literally. When I see "nosql" that now tranlates into "that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees". So at least it means something (to me anyway), and it's abstracting quite a mouth full. Much better than "Web2.0" was. That always just translated simply to "ajax with nice UI" for me, but I saw the term used in so many ways that didn't fit that definition.
  - zorked 15y ago
    "that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees" is exactly what the term means. So I guess it works.
    - 15y ago

michaelmior 15y ago

I agree that NoSQL is a strange term, although perhaps not quite for the same reason. I agree with the statement by @batista that SQL in this context is a defined way of thinking about problems. But NoACID seems much more appropriate especially as many "NoSQL" systems get SQL interfaces stuck on top.