Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jwall@google.com designates
 216.239.33.17 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
	content-type:x-system-of-record;
	b=gbqt6H8ULgiGH/R1cj64yKFKqrPL02lj+Vrl6pvtiqumIlxVWKrnXNAh6Epy1irBR
	WjFdCjvuelFM5mIF6LPtA==
MIME-Version: 1.0
In-Reply-To: <64a10fff0902120746j187aff2bpc1e5585b32007497@mail.gmail.com>
References: <4b307fd10902120242v3bbbc93fs92c88503eb632fe9@mail.gmail.com>
	 <64a10fff0902120746j187aff2bpc1e5585b32007497@mail.gmail.com>
Date: Thu, 12 Feb 2009 09:53:51 -0600
Message-ID: <7c40ded80902120753j63b1b29dn6c79f9bb0187e010@mail.gmail.com>
Subject: Re: playing with tags
From: Jeremy Wall <jwall@google.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0016361e86c0116b010462baba2e

--0016361e86c0116b010462baba2e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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" <dean@deanlandolt.com> wrote:

On Thu, Feb 12, 2009 at 5:42 AM, Nicolas Clairon <clairon@gmail.com> 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

--0016361e86c0116b010462baba2e--