On Wed, Feb 11, 2009 at 1:28 PM, Wout Mertens <[email protected]> wrote: > On Feb 11, 2009, at 7:22 PM, kowsik wrote: > >> Just something that occurred to me and wanted to run it by you guys. >> For pcapr, I have a number of different types of documents in >> couch-db, some are comments, some are about the packets, etc. Now, I >> have views that do something like this: >> >> map: function(doc) { >> if (doc.type == 'comment') emit(...); >> } >> >> With a large set of documents and a large set of views, any new >> document or updates to document is passed to __all__ of the views >> (when the view is eventually invoked). But I "know" that my documents >> come in classes and that only certain views really apply to them. I'm >> thinking of a view as a static method on a class that gets some >> information about the instances. >> >> What I'm getting at is, does it make sense to have some type of >> document "class" attribute and then have views bound to these classes? >> The goal, of course, being that couch-db can pre-filter a lot of these >> things and only run the views for the appropriate types of documents. > > I'm probably speaking before my turn being such a newbie, but why wouldn't > you create a new database for disjoint classes of documents? > > Also, once a view is run on a document, it doesn't get re-run that often > does it? > > So other than eating diskspace, maybe there's not really anything wrong with > keeping everything in one db. > > Wout. > >
There's nothing at all wrong with keeping lots of multiple document types in a single database. 1 db != 1 table etc etc. When a view is rerun it is only executed once for each document that changed. It doesn't matter how many times the document changed either. HTH, Paul Davis
