Why would you lose the ability to map through the data. Nothing prevents the map from working with both kinds of document. What exactly do you see yourself losing there?
Sent from my G1 google phone On Feb 12, 2009 9:47 AM, "Dean Landolt" <[email protected]> wrote: On Thu, Feb 12, 2009 at 5:42 AM, Nicolas Clairon <[email protected]> wrote: > Hi there ! > > I'm pl... This is an issue that has been nagging at me lately. Storing tags in the doc seems like a recipe for disaster (that is, if you consider view contention disaster). I would argue that tags (and other readily changeable user-specific state information like read/unread, favorite, blah blah) should be kept in separate docs and bridged together in views. Of course, doing this means you lose the ability to map through this data (e.g. no tag clouds), so it's a lose/lose right now. This is something I just can't figure out how to get around without a map/reduce/map kind of paradigm. Paul Davis mentioned some ideas about value indexes and view intersections that may help here. Does anyone else have opinions on how best to design for this? Someone floated the article *Accountants Don't Use Erasers* [1] recently that further convinced me this kind of data should be external to the doc in question, but I'm at a loss for how to do this without sacrificing functionality. [1] http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx
