Hello, kinda late, but better then never :)
(1) What kind of issues do you take into consideration when deciding if certain types of documents should go into their own database ?
Mainly the impossibility of map/reduce views to work accross databases. If you split data into separate dbs, and you need some reporting accross all those "accounts", you have to do some replication (of a subset of docs) into some "common" database. The same applies to fulltext indexing such as CouchDB-Lucene.
(2) Are your decisions based on performance, security or some other considerations ?
We have a media monitoring application and have decided to put data for every application account into a separate database, mainly because:
* It simply much cleaner this way :) (NB: you can name your dbs like "someprefix/dbname", and this is also the path on the disk.) * We are able to make the db accesible to the account _directly_ by mapping in a frontend webserver. So they are able to use the "raw data", not only the application API. We consider this to be the main benefit. * We earn an additional layer of security for free with this setup, which is nice. * We are able to very quickly and easily check sizes of dbs, view files, etc of accounts, eg. just by looking int Futon for the most cases * It would be rather easy (or so we think :) to "manually shard" the data accross different machines (eg. accounts A-M go to machine S1, N- Z to machine S2, etc)
(3) What else should I be asking you - if I was not a noob ;?)
Well, maybe just providing the context of your app. I'd say anywhere where you have something like "user inboxes", or something like "every user/account has their own data and we don't need to query accross them" (our case) is a good candidate for separate dbs.
Karel
