You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by wh...@aol.com on 2010/08/13 06:12:03 UTC

couchdb for aggregating data

I just wanted opinions on a site I'm building that converts meals into overall nutrition statistics.
Currently it's in mysql and php.

It tracks what people eat and breaks it down into nutrients as follows.
Each meal is composed of recipes which are composed of foods -- like a burger is beef, pickles, bun, catsup, mayo, etc.
Each food has 150 nutrients associated with it.
So for each person's day it's got to go ,meals-recipes-foods-nutrients then output a total of each of 150 nutrients in the USDA database.

Right now we are running into major problems querying the data for more than 200 days. The mysql query is almost unreadable.

Would couchdb offer advantages for this sort of database problem?

Thanks for any opinions.

Dan


 

 



Re: couchdb for aggregating data

Posted by Nicholas Orr <ni...@zxgen.net>.
seems like mysql would be able to handle this just fine... move a lot of
your processing to the application and away you go :)

what you could use couchdb for maybe is storing the results of processing
the raw data, leave mysql as a lookup table. so a person comes along and
says they ate a meal, as soon as they do this process the
meal-recipe-foods-nutrients and store the result in a couchdb document.

if you structure these couchdb documents well then querying for statical
info should be fairly straightforward and I'd imagine with the use of lists
couchdb could do most of the heavy lifting.

I don't know if the above would actually work, it is just what I thought of
as i read your email :)

Nick

On Fri, Aug 13, 2010 at 2:12 PM, <wh...@aol.com> wrote:

> I just wanted opinions on a site I'm building that converts meals into
> overall nutrition statistics.
> Currently it's in mysql and php.
>
> It tracks what people eat and breaks it down into nutrients as follows.
> Each meal is composed of recipes which are composed of foods -- like a
> burger is beef, pickles, bun, catsup, mayo, etc.
> Each food has 150 nutrients associated with it.
> So for each person's day it's got to go ,meals-recipes-foods-nutrients then
> output a total of each of 150 nutrients in the USDA database.
>
> Right now we are running into major problems querying the data for more
> than 200 days. The mysql query is almost unreadable.
>
> Would couchdb offer advantages for this sort of database problem?
>
> Thanks for any opinions.
>
> Dan
>
>
>
>
>
>
>
>

Re: couchdb for aggregating data

Posted by Kenneth Tyler <ke...@8thfold.com>.
Dan,
I assume that what each person eats does not change after the record is created.
Say you had documents that were recipes, which had lists of nutrients.
Then a meal document would have a list of recipes, but it would also
have the totals for all the nutrients in all the recipies.
A persons day document would combine the information about the person
and names of the meals they received and totals for the nutrients.
This is a calculate as you go strategy... that trades off data storage
space for complexity.
It makes the set of person-day documents more like something you'd
find in a datawarehousing setup

ken tyler
On Thu, Aug 12, 2010 at 9:12 PM,  <wh...@aol.com> wrote:
> I just wanted opinions on a site I'm building that converts meals into overall nutrition statistics.
> Currently it's in mysql and php.
>
> It tracks what people eat and breaks it down into nutrients as follows.
> Each meal is composed of recipes which are composed of foods -- like a burger is beef, pickles, bun, catsup, mayo, etc.
> Each food has 150 nutrients associated with it.
> So for each person's day it's got to go ,meals-recipes-foods-nutrients then output a total of each of 150 nutrients in the USDA database.
>
> Right now we are running into major problems querying the data for more than 200 days. The mysql query is almost unreadable.
>
> Would couchdb offer advantages for this sort of database problem?
>
> Thanks for any opinions.
>
> Dan
>
>
>
>
>
>
>
>