Why CouchDB?

So where do you put the logic, business rules, integrity constraints that govern this data? In stored procedures, key constraints? Or does it leak into the application code, especially if the code is OO. Using OOP how do the objects map to the tables? Some high level abstraction like hibernate that presumes to make that declarative and automatic? Now what if the schema is not so static, suppose it's dynamic. How does it evolve?

I think what many have recognized is that there is considerable overlap in the db world with app servers and web servers. The web is a much more dynamic place and increasingly I think relational databases are used more for just simple storage.

We've all used RDBMS for years and they've had loads of PhD theses put into making them what they are. Sometimes a different view is helpful. CouchDB has a dirt simple REST based API. It uses JSON for communication and Javascript in the database. It lets you store almost anything you want and it supports replication. For a real world scenario think of say something like a web-based lotus notes that supports on and off line use and collaboration.

Another very interesting aspect of CouchDB is it's choice of implementation language, Erlang. What it inherits from OTP is readily seen in the small amount of code needed to implement it. Moreover when it comes to robustness Erlang is frightening in how rock solid it is.

For what it's worth I think it's a keeper

> I've read tons of documents, articles, and how-tos on schema-free non-RDBMS DBs like SimpleDB, CouchDB, BigTable, DBSlayer etc. by now and I agree they seem very interesting and powerful. However, I just don't see how having each document (e.g. invoice) have it's own field structure would be a good thing. Every database I've ever worked on is structured and every new document has almost always the same data as every other document. That is not because of the limitations of the database but rather the nature of the business. Every invoice should have the same exact fields as every other invoice because employees are trained to fill and understand the implications of the data in each field. This has a lot more to do with business process efficiency and nothing to do with computers. RDBMS just facilitate that business rigidity more naturally. Of course, nobody's saying I can't do this in CouchDB but then why use CouchDB if I don't need the fluid document structure?

It is not useful if every document has its own structure :) But being able to model subtle differences like e.g. fax numbers in address records (basically that is a NULL-column in a relational table).

> Also, the biggest question I have is, how powerful are the dynamic views? I have tables with 10m rows and often serve 100+ select queries per second with joins/where/having/order/group-by/full-text-search functions. The business goal is not to make group-by queries but to summarize data in real-time as the analysts want e.g. sales by product per day or shipments by employee per week. How fast would a view that performs an equivalent function work on CouchDB? Can I optimize it somehow because I don't see much mention of index colums anywhere?

There are two kinds of views in CouchDB, temporary and permanent views. Temporary views should only be used in development on small amounts of data. Permanent views can do the exact same things temporary views can do, except their results are cached. For dynamic lookups you use the view key range that you can query in numerous ways as well as reduce that lets you do all sorts of computations. Something like average/total/max spending over a dynamic period of time (last week, last month, last year) can be generated from a single view in O(log n) time (where n is the number of documents). Concurrent reads happen non-blocking. I have seen a couple of hundred req/s on a view running on a dated MacBook.

> What bugs me most is that when dealing with databases like CouchDB and SimpleDB, the "best practice" advice I hear is to just write summary data and search indexes on my own. That is every time a new invoice is generated, add +1 to the summary.count.invoice record, add +300 to the balance.customer.acme-corp record and -5 to inventory.widget record. And don't forget to add every unique word in the document to the search index table. While that would be great if I knew the exact business needs ahead of the time but in reality, first you capture all the data you can capture and then generate reports based on the needs of the user.

I can't speak for SimpleDB, but in CouchDB the housekeeping is done for you automatically if you created a view for all your stats & things. You can even notify external services (fulltext search) to index new or changed data).

On your point: You can still manage relations in CouchDB, they are just implicit.

1. Couchdb is not installed and available everywhere like mysql.

2. The API is not stable (they haven't reached 1.0 yet), so code you wrote for it a year ago does not work on versions today. Code you write for it today will likely not work in two years time.

This is 'why not couch db' for me.

CouchDB is different from a relational DB in so many ways its almost silly to be doing the comparison. However, many people use and understand SQL, so we must show them what differences to expect.

Your argument about normalization being more realistic has its place. CouchDB models documents, which by necessity are somewhat complete, even when taken from their original context. Document modeling is radically different from relational modeling.

In document modeling, more emphasis is placed on the document life-cycle as opposed to inter-record normalization (relations). And in document modeling the client has a greater responsibility for saving data that is useful to the user, rather than asking the relational store to reconstruct the objects.

I think there are a lot of uses for CouchDB alongside relational DBs, but I'm especially excited to see what kinds of crazy things people figure out how to do with p2p offline replication.