Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4b307fd10902120242v3bbbc93fs92c88503eb632fe9@mail.gmail.com>
References: <4b307fd10902120242v3bbbc93fs92c88503eb632fe9@mail.gmail.com>
Date: Thu, 12 Feb 2009 10:46:27 -0500
Message-ID: <64a10fff0902120746j187aff2bpc1e5585b32007497@mail.gmail.com>
Subject: Re: playing with tags
From: Dean Landolt <dean@deanlandolt.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd485648ee55e0462ba9fde

--000e0cd485648ee55e0462ba9fde
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Feb 12, 2009 at 5:42 AM, Nicolas Clairon <clairon@gmail.com> wrote:

> Hi there !
>
> I'm playing with tags these time and a question comes to me.
> For exemple, I have a bunch of blog articles:
>
> article1 = {
>  ...snip...,
>  tags : ["couchdb", "python", "best practices"],
> }
>
> article2 = {
>    ...snip...,
>    tags : ["python", "best practices"],
> }
>
> article3 = {
>    ...snip...,
>    tags : ["couchdb", "best practices"],
> }


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

--000e0cd485648ee55e0462ba9fde--