solutions wanted recipe management solution??

[sugarseattle]

Solution: recipe management solution??

Description: First, am I in the right forum?

I am trying to figure out how difficult it would be to take the sample recipe database on the filemaker site and add a couple of functions.

#1, create an ingredient database with associated costs of ingredients and their common supplier. Seems easy enough. then I could have a pulldown menu when I enter in the recipe. then when the cost of ingredients changes, I can modify the database and it will automatically be reflected in the recipe.

#2 add the funcitonality of sub-recipes, meaning I could create sub recipes like tart crust and lemon filling and then make a composite recipe called "lemon pie". but since the ultimate function of this database is to cost recipes, i want that new "composite" recipe to also reflect revised cost figures.

I've used filemaker about 10 years ago, so I'm a little behind, but I think I could pick it up again...

Working Under:

Solution Status: Beta

Pre-requisites:

Author(s): sugarseattle

Date: 08/22/07

Credits:

Instructions / Other Info:

Disclaimer:

FM Forums does not endorse or warrantee these files are fit for any particular purpose. Do not post or distribute files without written approval from the copyright owner. All files are deemed public domain unless otherwise indictated. Please backup every file that you intend to modify.

[Twd70]

you need 4 more tables.

ingredients,

ingredients used,

suppliers,

ingredients supplied.

I know you didnt ask for the ability to see who supplies what or for more that 1 supplier to supply an item, but its good design for later.

for sub-recipes:

create a field in 'recipes' called 'parent'

if you then join 'parent' to the 'recipes' key field whenever you enter an ID into the 'parent' field it can appear in a portal for that parent recipe.

e.g.

ID Name Parent

1 Lemon Pie

2 crust 1

3 lemon mouse 1

A portal in lemon pie would show 2 and 3 as its 'children' recipes.

Total from ingredients used, and 'child' recipes would allow me to get a total for lemon pie.

I think i made that seem overly complicated....

Tom.

[Fenton]

I think it would be better to use a "join" table for the "parents", because several recipes might use the same crust, etc.. The join table would need Recipe ID of the "parent" recipe, the Recipe ID of the "child", and possibly the quantity of this child in the Recipe, if needed.

The biggest problem with the above is naming the two fields so you don't confuse them, ever.

Recipe would link "in" from a parent recipe, to the join Table Occurrence (TO), from RecipeID to RecipeParentID, with [x] Allow creation of related records (to add a child recipe in a portal).

The cost data would always sit in its recipe record, and be added up dynamically. The join table would also link to another instance of the Recipe table, a new TO. Because you cannot go in a loop. The relationship would be RecipeID to RecipeID; to see the name and the cost.

Recipe:

_cCost = sum (Ingredients::Cost) // direct ingredients

+

sum ( join TO->new Recipe TO->new Ingredients TO::cost) // may be 0

Caveat: I cannot explain this well in words; the names are too similar. The above may not even be right! If the original poster would post a small example file I could do the joins.