On Mon, Apr 12, 2010 at 2:42 PM, Jonathan Rochkind <[log in to unmask]> wrote:
> Yeah, I may have gotten it completely wrong.
>
> Okay, help this grasshopper (possibly by pointing me to relevant
> documentation), what's the difference between "document-based" and
> "key-value store"?  When I've looked at CouchDB before, despite it
> describing itself as "document based", I haven't been able to tell what the
> difference is between it and a "key value store".  It seemed to support
> storing a "document" by key, and retrieving it by key.  It didn't seem to
> _do_ anything special with the document other than storing it there (maybe
> it DOES, but I missed it?).  So you can call it a "document" instead of a
> "value", but I couldn't figure out how that differed from a key-value store.
>

I'm guessing just scope and focus. You could use mysql as document or
key-value store. Each row a document w/ collection of keys (column)
and values. But what you can do with the data really defines it. Redis
has collections of key/values but they are termed sets and lists and
the functions you have to work with them (like intersections, pop,
put, etc) center around that type of construct. Couchdb has
collections of key/values (json datatypes) but some of the functions
tend to be "document" oriented w/ revisions and updates being centered
around the whole json record versus just pairs within it.

You could put your logs, marc records broken out by fields or
arrays/hashes (types in couchdb) in any of them but the approach each
takes would limit you (or empower you) differently.

eby