[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.
http://cooktools.forevermore.net/sql/
some code is at:
http://cooktools.forevermore.net/includes/
http://cooktools.forevermore.net/test.php.txt
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.
-Chris
More information about the mythtv-dev
mailing list