Both are non-distributed (in the autopartitioning sense that everyone but couch uses the term, rather than the "distributed" as in Lotus Notes of couchdb), both have robust, non-sql query models, ...
So yeah, for the categories he defines, that's what makes sense.
The magic in this case being "for the categories he defines." I do so much enjoy articles that re-define the general consensus on terms so that the author can try to shift entries among categories in a way that makes their product look better. It feels like watching a biologist try to create a taxonomy based on "greenness" and "whether or not this creature tastes good when served with hollandaise sauce."
> Many web developers are non-advanced users of SQL anyway, not using "advanced" features like foreign keys, JOINs, inner queries or stored procedures.
I weep for the future. If you think a join is an advanced feature, then yeah, you're better off with CouchDB.
In CouchDB, unlike in MySQL, you come to understand what a join actually is - when it happens and what it costs performance wise.
What I like about CouchDB is that it's composed of a relatively small number of concepts. The more I code the more I prefer tools & libraries that utilize only a small number of concepts- the complexity, if it exists, is safely quarantined into the non-reusable application portion of the code and not in the tools I used to build it.
One can easily estimate the cost of a query in a relational database via EXPLAIN.
What relational databases do is decouple such implementation details from semantics, enabling higher levels of abstraction and therefore reasoning. Similarly, I'm happy to abstract the low-levels details of dictionaries in Python and not code my own hash table from scratch, or to use a compiler and not write assembly language. And while there are inevitable corner cases where hand-coded logic will outperform what a system can guess, handicapping yourself for a few extra cycles is something routinely (and rightly) derided in most programming circles.
Nobody debates that NoSQL systems are great for hand-tuning corner cases like these. It's the idea that they are a viable alternative to the relational model that is so objectionable, as it's a step backwards in abstraction.
I'm not sure if the NoSql movement is confused, but they definitely chose a confusing name. I was glad to see this blog post, because I do think it's useful to categorize some of the reasons people want to say "no" to "sql".
I'd add "level of abstraction" to this list (ie., people say no because SQL provides the wrong level of abstraction for a problem). You know you're getting old when when the "high level" languages of your youth are now viewed as "low-level" building blocks, but this has clearly happened in the SQL world. I initially resisted hibernate, JPA, active record, and so forth, probably for the same reason some C/C++ programmers resisted Java's memory management - it felt strange to give up this control. Now that I've gotten used to these tools, I'd never want to go back to hand-written SQL for basic object persistence and relational mapping, and I'm more than happy to use JPA or ActiveRecord to automate my CRUD. In this sense, I'd say "NoSql" for the same reason I'd rather have garbage collection than malloc or the pointer asterisk.
But I do see huge and fundamental memory mistakes made by people who use ORM abstractions without understanding SQL (such as selecting all into an arraylist and filtering through code rather than using the where clause, or generating a list and using each element to generate a new list, rather than using a JOIN).
It could be that some of these folks never encounter a data set large enough or a relation complex enough to need SQL, or maybe SQL is actually not necessary to manage relations in huge, intertwined data sets, or maybe you can avoid huge, intertwined data sets through careful planning. But for me, this is where the "NoSQL" thing breaks down, and I definitely haven't heard a whole lot of discussion about it.
That's because 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".
That makes sense, sounds like it got away from you (kind of like "agile", which has lost a lot of its original meaning).
But there's a reason it got away from you, and that "NoSql" struck a broader chord. There are a lot of reasons people would say "no sql". Some of them are good, some of them are ill-considered, and some are probably just a matter of personal preference. I personally like sql and relational algebra, but that doesn't mean I enjoy writing a lot of dull sql for crud apps, so even a SQL fanboy like me does see some merit to a more general "no sql" movement. I'm just interested in trying to figure out/catalog the various objections, why people have them, whether they are based on a misunderstanding of SQL/RDBMS or are very valid, and so forth. I think it's a good discussion.
14 comments
[ 4.5 ms ] story [ 44.9 ms ] threadSo yeah, for the categories he defines, that's what makes sense.
> Many web developers are non-advanced users of SQL anyway, not using "advanced" features like foreign keys, JOINs, inner queries or stored procedures.
I weep for the future. If you think a join is an advanced feature, then yeah, you're better off with CouchDB.
What I like about CouchDB is that it's composed of a relatively small number of concepts. The more I code the more I prefer tools & libraries that utilize only a small number of concepts- the complexity, if it exists, is safely quarantined into the non-reusable application portion of the code and not in the tools I used to build it.
What relational databases do is decouple such implementation details from semantics, enabling higher levels of abstraction and therefore reasoning. Similarly, I'm happy to abstract the low-levels details of dictionaries in Python and not code my own hash table from scratch, or to use a compiler and not write assembly language. And while there are inevitable corner cases where hand-coded logic will outperform what a system can guess, handicapping yourself for a few extra cycles is something routinely (and rightly) derided in most programming circles.
Nobody debates that NoSQL systems are great for hand-tuning corner cases like these. It's the idea that they are a viable alternative to the relational model that is so objectionable, as it's a step backwards in abstraction.
Not all applications need the powerful abstraction of SQL. Many do and _many_ don't.
I'd add "level of abstraction" to this list (ie., people say no because SQL provides the wrong level of abstraction for a problem). You know you're getting old when when the "high level" languages of your youth are now viewed as "low-level" building blocks, but this has clearly happened in the SQL world. I initially resisted hibernate, JPA, active record, and so forth, probably for the same reason some C/C++ programmers resisted Java's memory management - it felt strange to give up this control. Now that I've gotten used to these tools, I'd never want to go back to hand-written SQL for basic object persistence and relational mapping, and I'm more than happy to use JPA or ActiveRecord to automate my CRUD. In this sense, I'd say "NoSql" for the same reason I'd rather have garbage collection than malloc or the pointer asterisk.
But I do see huge and fundamental memory mistakes made by people who use ORM abstractions without understanding SQL (such as selecting all into an arraylist and filtering through code rather than using the where clause, or generating a list and using each element to generate a new list, rather than using a JOIN).
It could be that some of these folks never encounter a data set large enough or a relation complex enough to need SQL, or maybe SQL is actually not necessary to manage relations in huge, intertwined data sets, or maybe you can avoid huge, intertwined data sets through careful planning. But for me, this is where the "NoSQL" thing breaks down, and I definitely haven't heard a whole lot of discussion about it.
It was just a tongue-in-cheek name, until someone came along and decided it was a "movement".
But there's a reason it got away from you, and that "NoSql" struck a broader chord. There are a lot of reasons people would say "no sql". Some of them are good, some of them are ill-considered, and some are probably just a matter of personal preference. I personally like sql and relational algebra, but that doesn't mean I enjoy writing a lot of dull sql for crud apps, so even a SQL fanboy like me does see some merit to a more general "no sql" movement. I'm just interested in trying to figure out/catalog the various objections, why people have them, whether they are based on a misunderstanding of SQL/RDBMS or are very valid, and so forth. I think it's a good discussion.