incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svilen ...@svilendobrev.com>
Subject Re: Best case for 1:many relation in CouchDB
Date Tue, 21 May 2013 14:37:19 GMT
my decision about tagging/classifying stuff is to keep tags/categories
as a document per category with all the tags inside, AND for each
tag keep all tagged-items-ids inside there too.

Thus items-to-classify are completely independent from classificator
and can be anything - only id's are used. Changes of classificator stay
in classificator.

one can split category from (sub)tag... depends on frequency/source of
updates and such.

This way it does take 2 queries to filter anything - one to get
ids-of-items, and another to fetch those items. 
But intersection queries (AND/join) aren't well doable anyway. 
http://wiki.apache.org/couchdb/View_collation
if u need many of those over vast number of rows, consider lucene plugin
or another such indexer that supports it.

as of hierarchical classification/grouping.. i do manualy all the ANDs
but my tags are not hierarchical. This came from semantical stuff where
same tag can have diff.meaning in diff.aspect/namespace, e.g. "joe" can
be a person itself, or ownership, or place, etc.

well, not sure if this is of any help..
svil

On Mon, 20 May 2013 18:29:08 +0200
Bernd Grolig <altbauwohnung_lehel@web.de> wrote:

> Hello,
> 
> I just started to set up an mobile App using TouchDB. It's the first
> time for me to work with a NoSQL Database. While setting up the
> basics so far worked very well, I stepped deeper in how to design the
> data structure of the app.
> 
> The principle question for me is, what is the best design for 1:many
> relations and for grouping.
> 
> I researched quite a lot in the web, but I am stil not sure, how to
> design it in the best way. Would be great to get some hints from this
> mailing list.
> 
> So this is the basic data structure:
> 
> Document type: Categories
> 
> {
>    "_id": "a124",
>    "_rev": "8-089da95f148b446bd3b33a3182de709f",
>    "detCat": "1st Category",
>    "mainCat": "Main Category",
>    "mainBereich": "Division",
>    "type": "Transaction"
> }
> 
> {
>    "_id": "a125",
>    "_rev": "3-089da95f148b446bd3b33a3182de232",
> 
>    "detCat": "2nd Category",
>    "mainCat": "Main Category",
>    "mainBereich": "Division",
>    "type": "Transaction"
> 
> }
> 
> Document type: Transaction
> 
> {
>    "_id": "7568a6de86e5e7c6de0535d025069084",
>    "_rev": "2-501cd4eaf5f4dc56e906ea9f7ac05865",
>    "Value": 133.23,
>    "Sender": "Sender Name",
>    "Booking Date": "11.02.2013",
>    "Detail": "Some Transaction details",
>    "catID": "a124"
> }
> 
> {
>    "_id": "23982304201948231213",
>    "_rev": "2-234123412342",
>    "Value": 199.23,
>    "Sender": "Sender Name",
>    "Booking Date": "11.04.2013",
>    "Detail": "Some Transaction details",
>    "catID": "a125"
> }
> 
> As long as I want to receive all transactions with its correlating
> category it is quite easy by using "include_docs=true" in the search
> string.
> 
> But as soon as I want to have a reduce or grouping e.g. to "MainCat"
> or to "Division" I could not find a good solution to solve this.
> 
> My question is, if there is a possibility to generate a map/reduce
> view to group to Main Cat or Division and sum all the transactions to
> this level?
> 
> The only possibility I see is to put the Category names and Main
> Category Names and Division Names inside the document type of the
> transaction. But this would cause a lot of work for updates when the
> name of a category is changed.
> 
> The other possibility would be to get the result without reduce and
> sum within the application logic, but this seems also not to be the
> very elegant way.
> 
> I think this is a very basic design question and used many times in
> the web, e.g. Tagging. However all examples I found only wrote the
> name of the tag or in my case category in the document itself.
> I'm curious to get some hints to solve this questions.
> 
> Best regards,
> Bernd

Mime
View raw message