incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: playing with tags
Date Thu, 12 Feb 2009 15:46:27 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message