3 ms·

From a development standpoint, I don't quite understand the advantages of NoSQL over SQL. I get that you don't have to have a rigidly defined table structure,

From a development standpoint, I don't quite understand the advantages of NoSQL over SQL. I get that you don't have to have a rigidly defined table structure, and that your data structure can change when your application changes, but I guess I'm one of those curmudgeons that prefers rigidity over permissiveness. I like that I have to think hard about my table structure and models before and as I code. I also rarely feel bogged down by SQL, although I've been using it for over a decade, so that helps. As for scalability, as this post shows, I think the best thing to come out of NoSQL is the race for greater scalability it has and will continue to inspire in SQL solutions.

steveklabnik 16y ago
There are some times when the standard normal form is a real pain, for example, and your data fits better as a document or a simple key-value. I mentioned one such instance for me here: http://news.ycombinator.com/item?id=1637903 http://news.ycombinator.com/item?id=1637903
- davidmathers 16y ago
  I think you're making the common mistake of confusing relational databases with entity-relationship modeling. I can't really figure out your foo example though, needs to be a bit more specific.
AndrewO 16y ago
"NoSQL" has come to symbolize a number of different things, depending on who you're talking to and when. I've seen all combinations of one or more of the following: 1. The rejection of what some see as an overly complicated and inflexible query language in favor of map-reduce phases or other application-side querying/processing. 2. The rejection of serialized transactions in favor of something like eventual consistency, often with application-specified conflict resolution. 3. Or it could be a rejection of the relational model (especially as it is popularly implemented) in favor of key-value, graph, document, column-oriented, etc. models. If I read you and the authors right, I think you're thinking more along the lines of 3 and the authors are focussing more on 2. I think both "sides" are just starting to come to grips with the idea that these design choices can be orthogonal (a relational DB without SQL? an eventually consistent SQL DB? a graph DB with 2-phase commit?) and choosing to reject one part of "the old way" doesn't mean you have to reject all of it. The upshot is, we're going to have a lot more tools to choose from for our own unique problems. So, I'd say: don't worry about feeling like a curmudgeon! Rigidity will have its place in the beautiful gleaming pluralistic future of datastores that the SQL vs. NoSQL "debate" is building the road towards.

steveklabnik 16y ago

There are some times when the standard normal form is a real pain, for example, and your data fits better as a document or a simple key-value. I mentioned one such instance for me here: http://news.ycombinator.com/item?id=1637903 http://news.ycombinator.com/item?id=1637903

davidmathers 16y ago
I think you're making the common mistake of confusing relational databases with entity-relationship modeling. I can't really figure out your foo example though, needs to be a bit more specific.

AndrewO 16y ago

"NoSQL" has come to symbolize a number of different things, depending on who you're talking to and when. I've seen all combinations of one or more of the following: 1. The rejection of what some see as an overly complicated and inflexible query language in favor of map-reduce phases or other application-side querying/processing. 2. The rejection of serialized transactions in favor of something like eventual consistency, often with application-specified conflict resolution. 3. Or it could be a rejection of the relational model (especially as it is popularly implemented) in favor of key-value, graph, document, column-oriented, etc. models. If I read you and the authors right, I think you're thinking more along the lines of 3 and the authors are focussing more on 2. I think both "sides" are just starting to come to grips with the idea that these design choices can be orthogonal (a relational DB without SQL? an eventually consistent SQL DB? a graph DB with 2-phase commit?) and choosing to reject one part of "the old way" doesn't mean you have to reject all of it. The upshot is, we're going to have a lot more tools to choose from for our own unique problems. So, I'd say: don't worry about feeling like a curmudgeon! Rigidity will have its place in the beautiful gleaming pluralistic future of datastores that the SQL vs. NoSQL "debate" is building the road towards.