[mythtv] mythrecipe

Chris Petersen lists at forevermore.net
Tue Nov 9 09:09:46 UTC 2004

>>1 cup plus 2 tbsp flour
> for this scenario I would have either split this up into 2 ingredients or done:
> qty|amt|ingredient
> 1 | cup | plus 2 tbsp flour

No.  it would be stored internally as 1.125 cups and parsed into a 
human-readable size upon display (there are 16 tbsp in a cup).  My 
example was more to show the kind of things you would need to parse (for 
input) and display.

>>1 squeeze of lemon or lime
> for this scenario I would have squeeze be the amount and then lemon or
> lime as the ingredient.

squeeze is a unit, yes.  and there would be two separate ingredients. 
You wouldn't want to create an ingredient called "lemon or lime" -- 
you'd want to link both to "lemon" and to "lime".

> Of course I would be open to other suggestions because if we have some
> sort of scale function it would probably get messed up. Of course I
> don't know if there would be a way to make something that would scale
> in all cases.

I have all of this done in php already.  It's borked at the moment 
because I made some semantic changes to make it easier to expand (better 
objects), but wouldn't be too hard to fix.

>>Dinner -> Entree -> Rice -> Risotto
>>Region -> Italy  -> Dinner -> Entree -> Risotto
> here I see two different categories, the first one has a main category
> with two subcategories and the second would be a search by region. So
> perhaps a search by region which would filter the results by whatever
> region they selected (in this case Italy) and then continue to search
> by category but filter out anything not matching said region. That
> shouldn't be too hard to do with sql.

Yeah.  Just showing that there could be multiple category branches to 
the same destination recipe.

> For the category but, I guess have a main category and then a
> subcategory field. Sound good?

Basically, each category is a node.  There is one parent node, and when 
you create a new node, you tell it where its parent is.  Easy to do, and 
you can do some magic to make multi-homed categories, it's pretty cool.

> Your list:
>> - table of ingredients, complete with descriptions, images and
>>     nutritional info
> Do we really need images of ingredients? 

No.  But for the long term, I have the idea of creating a culinary 
database.  Does everyone know what a quince looks like?  Or fresh wasabi 
root?  I'm fascinated by databases, and by food.  So I look to the 
extreme in this sense.

>> - table of recipes, linked with recipe-ingredients
> So like a lookup table that has a recipeID and an ingredient?

one table for recipes, one for ingredients.  one record per recipe, one 
per ingredient.  ingredients link to recipe_id.

>> - a category tree not directly linked to recipes (trust me, it's easier
>>     to manage this way), but assigned keywords.  Recipes matching those
>>     keywords will show up under that category.
> This may be easier in terms of data entry but invites a whole lot of
> other complications. First the queries would take longer than if we
> have to search through keywords rather than just pull out the
> information.

It's negligbly slower.  All keywords are in a related table, so you're 
comparing numerical entries.  It might get slow when you start getting 
in to the tens/hundreds of thousands of records per keyword, but with 
anything reasonable, especially with query caching, it shouldn't be a 
problem (I've written systems far more complex than this and there's no 
issue -- heck, the program listing query in mythweb is worse)

>> - each recipe/ingredient gets a unique identifier, like a wiki.
> Yeah, that way you can delete an individual item

you can do that with record id's.  the unique identifier gives you a 
static human-readable URL that can be used to bookmark a specific recipe.

> so do you have an existing database setup? If you get a chance I would
> like to see how your data structures are laid out and if you don't
> already have a database setup then we'll see what we can do.


some code is at:


keep in mind, it's borked at the moment, but it'll give you an idea what 
I got in the few days I was able to spend on it.

> I understand you are busy moving into your new house, I too will be
> closing on my first house soon so this may be a little slow going.

Slow is good for me -- nuvexport and mythweb need attention before I can 
put much effort into this, too.

congratz on the house -- it's quite an experience.


More information about the mythtv-dev mailing list