I’m modelling a document generation system in couchdb. It semi-automates the production of proposal and presentation documents from managable document fragments.
Much like, say, Basecamp, it breaks down very simply into self-contained data per ‘account’. Each account has multiple users, projects, documents, etc. However, nothing should be shared between accounts.
I can see two ways of doing this:
- one couchdb database per account
- use a namespace / property to identify the account
It seems to me that the first approach is conceptually sound and potentially has security and partitioning advantages. However, it seems to me to restrict some cross-database data querying (that I don’t have a use case for now but you never know…) and to make updating views potentially require an awful lot of writes.
Does anyone experienced with this kind of decision have any advice?
That is an accurate summary of the situation and I do not think there is a silver bullet answer. It all depends on how likely you are to need information or reports across the entire user base.
I would remind you of two things:
Business applications very quickly develop a need to run reports you never thought about when you architected the software. What will you do when a customer has five accounts and he insists your total fees are not what they should be? A characteristic about these reports is that you usually need them as quickly as possible.
However, you can always use replication to merge all databases into one gigantic database (even on a separate machine) in order to run reports on that one. If your keys do not collide, that would save you a little bit of effort but in general you can make this work.