Re: [Cronometer-development] Measure/Serving in the database

[Aaron D. <ada...@po...>]

On Apr 27, 2005, at 8:31 PM, Chris Rose wrote:

> I'm thinking of moving Measure and Serving over to the same interface
> format as Food -- this would force creation of Datasource-specific
> models of each of them which may or may not be what we want.

I suppose...

> One, both of them are essentially first-class objects in the backing
> datastore.  Measures and Servings have their own tables, and their own
> unique IDs.  This suggests pretty strongly that they should be
> represented directly.
>
> Two, it might provide better and faster lookups.

Why? How?

> Three, I suspect (don't quote me) that it might be easier to manage
> them in the datasource if it can be guaranteed that they all share the
> same basic source for their information.

i.e, a Measure for a Food both must be from the same datasource?

> One possible hiccup that occurs to me is the one base measure -- a
> gram.  This would now have to be gotten from each datasource as a
> datasource-specific quantity - this isn't fatal, but it is a bit
> grotty.

Yeah, hmmm. It's kind of a universal Measure, and we don't want a gram 
Measure
entry for every single Food, since it's a huge waste.

> I've looked at the calorieking website, and it doesn't look like they
> expose any webservices for their databases, which means we're going to
> have to write a screen scraping library for it.  I'm not a big fan of
> that, but if it's what we have to do, so be it.  I'll start piecing
> together something that will allow me to test it directly, without
> having to bolt it into our current setup.

Yeah, I think all of these ones would be faking it through the forms.

> Also, what was the other site?  I want to check their site out, too.

nutritiondata.com