4 ms·

The NoSQL movement is growing, but what is it?

27 points by monkeygrinder 17y ago

Roridge 17y ago
Realistically we have all been creating NoSQL applications for some time. For years we have been hiding the SQL away from the Objects. EJB is a classic example of something that tries to keep the SQLugly away from applications. But NoSQL is like a breath of real-time fresh air for me. RDBMS have become stale and the flurry of NoSQL out there is exactly what the real-time web needs.
- AndrewDucker 17y ago
  We haven't _all_ been doing that. Some of us have been writing SQL applications that extract related data from multiple tables while maintaining integrity between them. Seems to work for us...
  - patio11 17y ago
    I really love key/value stores for things they work really well for -- caching comes immediately to mind -- but I would really, really, really not want to support $FOO university's 300 table, ~2,000 column, ER-diagram-occupies-an-entire-wall system if it were written in a key/value store.
  - deleted 17y ago
    [deleted]
  - geebee 17y ago
    I think that NoSql is a very regrettable name for an interesting movement. I got a response from someone who appears to have been involved in the early stages http://news.ycombinator.com/item?id=967882 http://news.ycombinator.com/item?id=967882 "...NoSQL was never meant to be a "movement". We were taking a trip to the Bay Area from London and we wanted to meet up with some of the guys who were working on scalable non-relational data stores. We planned a one-day conference and someone suggested naming it NoSQL. It was just a tongue-in-cheek name, until someone came along and decided it was a "movement". I can see how this happens. Unfortunately, a name like "NoSql" is going to get people to come to the defense of Sql in many ways that were never really part of the "NoSql" concept. For instance, my initial reaction was a defense of the language and its (in my opinion) remarkably effective way of structuring and managing complex relationships in data. However, it appears that most of the "NoSql" folk aren't making any claim to the contrary. NoSql, I think, is more about avoiding rdbms's as a default data store when you don't really need sql and are experiencing scalability issues. In that case, it probably does make sense. "NotAlwaysSql" might have been a more descriptive name, but doesn't really have the same impact... sometimes this is deliberate (get the impact of a controversial term, but then define that term as something much easier to defend), but in this case, I don't think it was deliberate, I think it was something that got away from them.
    - Roridge 17y ago
      Yes, it's a very unfortunate name, it's a shame it stuck. I'm not against SQL at all, I just like that the "movement" to provide an API to develop against at the points where SQL isn't necessary. It just saves me implementing it myself with the SQL behind it.
k7d 17y ago
This article sounds like a typical enterprise architect bullshit. And he is missing the point. NoSQL is so much more than simple KV store. NoSQL Wants To Be "Elastic Caching" When It Grows Up. What is he smoking?
helwr 17y ago
the article is very shallow. if you want a serious overview of "noSql movement" I recommend this paper: "No Relation: The Mixed Blessings of Non-Relational Databases" by Ian Varley http://ianvarley.com/UT/MR/Varley_MastersReport_Full_2009-08-07.pdf http://ianvarley.com/UT/MR/Varley_MastersReport_Full_2009-08...
inboulder 17y ago
I wish the energy being put into the whole 'nosql' movement had moved toward object databases instead of KV stores. KV is fine for caching, but is obviously not suitable for modeling and retrieving data with complex relationships. I think it's hilarious that some NoSQL solutions now have 'columns!', way to go, you're slowly reinventing the RDBMS, poorly...

27 points by monkeygrinder 17y ago

Realistically we have all been creating NoSQL applications for some time. For years we have been hiding the SQL away from the Objects. EJB is a classic example of something that tries to keep the SQLugly away from applications. But NoSQL is like a breath of real-time fresh air for me. RDBMS have become stale and the flurry of NoSQL out there is exactly what the real-time web needs.

AndrewDucker 17y ago
We haven't _all_ been doing that. Some of us have been writing SQL applications that extract related data from multiple tables while maintaining integrity between them. Seems to work for us...
- patio11 17y ago
  I really love key/value stores for things they work really well for -- caching comes immediately to mind -- but I would really, really, really not want to support $FOO university's 300 table, ~2,000 column, ER-diagram-occupies-an-entire-wall system if it were written in a key/value store.
- deleted 17y ago
  [deleted]
- geebee 17y ago
  I think that NoSql is a very regrettable name for an interesting movement. I got a response from someone who appears to have been involved in the early stages http://news.ycombinator.com/item?id=967882 http://news.ycombinator.com/item?id=967882 "...NoSQL was never meant to be a "movement". We were taking a trip to the Bay Area from London and we wanted to meet up with some of the guys who were working on scalable non-relational data stores. We planned a one-day conference and someone suggested naming it NoSQL. It was just a tongue-in-cheek name, until someone came along and decided it was a "movement". I can see how this happens. Unfortunately, a name like "NoSql" is going to get people to come to the defense of Sql in many ways that were never really part of the "NoSql" concept. For instance, my initial reaction was a defense of the language and its (in my opinion) remarkably effective way of structuring and managing complex relationships in data. However, it appears that most of the "NoSql" folk aren't making any claim to the contrary. NoSql, I think, is more about avoiding rdbms's as a default data store when you don't really need sql and are experiencing scalability issues. In that case, it probably does make sense. "NotAlwaysSql" might have been a more descriptive name, but doesn't really have the same impact... sometimes this is deliberate (get the impact of a controversial term, but then define that term as something much easier to defend), but in this case, I don't think it was deliberate, I think it was something that got away from them.
  - Roridge 17y ago
    Yes, it's a very unfortunate name, it's a shame it stuck. I'm not against SQL at all, I just like that the "movement" to provide an API to develop against at the points where SQL isn't necessary. It just saves me implementing it myself with the SQL behind it.

k7d 17y ago

This article sounds like a typical enterprise architect bullshit. And he is missing the point. NoSQL is so much more than simple KV store. NoSQL Wants To Be "Elastic Caching" When It Grows Up. What is he smoking?

helwr 17y ago

the article is very shallow. if you want a serious overview of "noSql movement" I recommend this paper: "No Relation: The Mixed Blessings of Non-Relational Databases" by Ian Varley http://ianvarley.com/UT/MR/Varley_MastersReport_Full_2009-08-07.pdf http://ianvarley.com/UT/MR/Varley_MastersReport_Full_2009-08...

inboulder 17y ago

I wish the energy being put into the whole 'nosql' movement had moved toward object databases instead of KV stores. KV is fine for caching, but is obviously not suitable for modeling and retrieving data with complex relationships. I think it's hilarious that some NoSQL solutions now have 'columns!', way to go, you're slowly reinventing the RDBMS, poorly...