Another consideration is data churn rate. If you have a set of documents that are changed or deleted frequently, such as login session data, you might want to put them in their own database and compact it more often than the database with the relatively static content.
On Friday, October 29, 2010, Zachary Zolton <[email protected]> wrote: > I'd also like to add that permissions are a common reason to put docs > into separate databases. For example, if each user should only see > there own docs, then you should give each user their own database. > (Given that CouchDB can only enforce read permissions at the database > level.) > > On Fri, Oct 29, 2010 at 4:07 AM, Nils Breunese <[email protected]> wrote: >> Op 29 okt 2010, om 10:37 heeft Zdravko Gligic het volgende geschreven: >> >>> (1) What kind of issues do you take into consideration when deciding >>> if certain types of documents should go into their own database ? >> >> It makes sense to store all documents used by an application in the same >> database. That way your data can be easily replicated along with your design >> documents. Only start separating data into different databases when there is >> a real need. If you can't explain why you need multiple databases, just >> start with a single one. Relax, you can always split out later. >> >>> (2) Are your decisions based on performance, security or some other >>> considerations ? >> >> No. (But maybe somebody else's are?) >> >>> (3) What else should I be asking you - if I was not a noob ;?) >> >> I have no idea. >> >> Nils. >> ------------------------------------------------------------------------ >> VPRO >> phone: +31(0)356712911 >> e-mail: [email protected] >> web: www.vpro.nl >> ------------------------------------------------------------------------ >> > -- Mark J. Reed <[email protected]>
