The Confused World of "NoSQL"
bytepawn.com
bytepawn.com
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.
> 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.
So yeah, for the categories he defines, that's what makes sense.