On Tue, May 26, 2009 at 09:52:08AM +0200, Jurg van Vliet wrote: > i think replication is not the solution for the specific problem i tried > to sketch. i am talking about simple aggregate information (10 most > recent documents per user, for example) over potentially thousands of > different databases. if i have to replicate all my databases into one big > database i would start with a big one and replicate out to handle load. > that feels like 'missing the point'. (though i am still struggling which > point exactly :) )
Possibly, having thousands of different databases isn't the right map to your problem domain, since you can't have a view spanning multiple databases. Multiple databases make sense where the data is entirely self-contained (data belonging to one user), especially for virtual hosting where it's a benefit that data cannot leak from one database to another. In an application I'm working on at the moment, I have one database per user - but a separate global login database holding the usernames and passwords and pointers to each user's database, so at login time I only need to query one view. > yes and no, it all depends on how you regard your users. i think in an > environment where many people create something together the conflicts > have meaning. i choose to expose the conflict, meaningfully, and 'help' > the user resolve it herself. Yes of course; I don't mean that automated conflict resolution is required. What I mean is - CouchDB *hides* the conflicts, whereas you and I want them *exposed*. It is not easy even to say "give me all conflicting versions of this document". Regards, Brian.
