The role of CouchDB's databases and design documents with regards to data types

Question

Let's say I have an app called "traveler" and I want to store People and Places. Both documents have wildly different properties and different views.

I see two logical approaches to storing this data:

1. In separate CouchDB databases, each with a single design document called traveler containing the views on that particular data type. Eg: /people/_design/traveler/_view/by-name.
2. In a single CouchDB database called traveler with one design document per data-type, and use something like a "type" property (or other way of ducktyping) to filter the views. Eg: /traveler/_design/people/_view/by-name.

What would be the idiomatic approach?

Answer 1

Both are perfectly valid approaches, depending on your needs.

The main thing to consider is whether or not you'll ever want to combine these documents in views. By using separate databases, you will preclude this possibility as views cannot span multiple databases. Of course, you can perform any sorts of joins in your application layer, so if you don't want to do this in the database at all there will be no difference to you.

In general, I find it's easier to stick to approach #2.