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