Olifante *'s Library tagged couchdb →  View Popular

the documented way to
talk to CouchDB is over HTTP, and because you send it JSON primitives
containing data structures, it can be used from just about any program
written in just about any language. And given that most folks are not
accustomed to being able to access any database without dark-magic C
bindings that speak strange connection-oriented TCP protocols (or the
equivalent embedded usually-crashy C bindings and awkward APIs), this
is probably a novelty for many users.

CouchDB has a built-in
indexing and querying facility, in the form of
Views.
This is something that ZODB does not share. Instead, ZODB relies on
applications that are built on top of it to provide indexing
capabilities. Moreover, creating indexes in applications that use
ZODB is historically a static kind of thing that the application
developer does "up front", or at least as a "software release" sort of
thing. In CouchDB, creating an index is not really an exceptional
sort of event. You tell the server, over HTTP, to create the index by
PUT-ing a view. The first time any view is queried, CouchDB does the
indexing. The following times the view is queried, it uses the index
you've created via the view to return the results faster. No
application that I know of written on top of ZODB allows you to do
such a thing so casually.

All in all, CouchDB is a neat piece of software. If I ever have to
build an application that needs to store data that needs to be
accessible from programs written in langauges other than Python across
HTTP and I don't need to use a relational database, it seems like a
great solution.

ZODB is probably still a better choice if your application is 100%
Python and you want arbitrary application database write logic to be
bounded within a single transaction.

if you need to store large amounts of
data (like arbitrary numbers of multimegabyte or multigigabyte files),
ZODB is also probably a better choice, as it has blobs built in, and
the blobs don't need to be base64 encoded in memory as "attachments"

if you need to
store data structures that cannot be represented as JSON (like complex
object instances), ZODB really can't be beat.

CouchDB no longer requires encoding
binary data in base64. Attachments for documents (that work just like email
attachments) have their own REST API since this summer where you can
send the raw binary data to create and retrieve documents. So storing loads
of data is no longer a bad idea.

You can think of a ZODB database
as a place to hang a graph of arbitrary Python objects that becomes
persistent. It's sort of an "uber-pickle"

You can use packages like
repoze.catalog to do indexing
and querying of object data that is inserted into the graph. You can
use packages like
repoze.folder to hold
large collections of objects.

The "Zope" in ZODB is a
"brand-only" name; it does not require Zope; it can be used in any
Python application.