

The Confused World of "NoSQL" - Maro
http://bytepawn.com/2009/11/28/the-confused-world-of-nosql/

======
geebee
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.

~~~
russss
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".

~~~
geebee
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.

------
wvenable
From article:

> 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.

~~~
swannodette
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.

~~~
njm
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.

~~~
swannodette
Sorry my comment wasn't meant to be construed as an attack on the usefulness
SQL, rather it was defending the usefulness of CouchDB.

Not all applications need the powerful abstraction of SQL. Many do and _many_
don't.

------
simonw
This article confused me. CouchDB and Redis in the same category?

~~~
jbellis
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.

~~~
evgen
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."

