Re: Why use multiple databases ?

[Karel Minařík <ka...@gmail.com>]

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