View Full Version : Help with "recipe" script that updates ingredients based on servings

01-10-2008, 04:36 PM
I have been asked to "throw together" a script that essentially shows a recipe drawn from mysql. The twist is that they want the visitor to be able to change the number of servings (default=4) and that will then update the measurements on the site.

We have a similar file in cgi that runs from two flat files (one with the title, image location, method and the second txt file, named the id number for the individual recipe, and each line has two fields, the number and the measurement/ingredient). I'm not a CGI person, and they are planning to do everything using mySQL from now on.

I need to be able to do something quick to show it can be done, so I was trying to just use the flat files from the earlier project, and code the php to make it do what I want, but I don't know if it's possible to include two flat files in one document, and if so, how to script that. Anyone know?

I will be putting the final project in a database eventually, and I have no idea how that could be structured so it works, but if anyone has any ideas/advice, I'm more than willing to hear it!

01-10-2008, 05:27 PM
What do you mean by flat files?:)

01-10-2008, 05:29 PM
It sounds like you need more help with PHP than just the formula to change ingredients. That formula is 3rd grade math.

So... what is your real question?

01-10-2008, 05:31 PM
Flat file as opposed to database. Also called sequential file, text file, data file.

01-10-2008, 05:34 PM
nikos, flat files are txt files that php draws data from. they are used when there's no access to a database.

fumigator, the "real" question is this:
I have no idea how that could be structured so it works

The equation is not the issue. The issue is that I can't sort out, in my head, how to set up the database so that I can pull the information the way I need it.

Setting up the recipe is not a problem, it's how to put in the ingredients. The original script has two files. One is the recipe without the ingredients, and the second is the individual recipe's ingredients, named for the recipe's id number, with each line containing two columns...one for the number and one for the measurement and ingredient.

Is there a more logical way to do it than that?

01-10-2008, 05:42 PM
EDIT: Not sure if you're asking how to put it in the database, or in the flat files. This is easy enough to put in a database. There isn't that much going on.


Table: Recipe

id, name, description, cookingtime (etc.)

Table: Ingredients

id, name, description (optionally: weight, nutritional values, etc.)

Table: Unit

id, name, shortname

Table Recipe_Ingredients

recipe_id, ingredient_id, amount, unit_id


All amounts in recipe_ingredients are for single (1!) servings. This makes it easy to multiply.

Join the tables together, and in the column clause of the select statement, multiply Recipe_Ingredients.amount times the number of servings. The query just needs 2 inputs: Recipe ID and Servings.

01-10-2008, 05:44 PM
Thanks so much Aedrin. I have been staring at another project so long that my brain won't think of anything beyond.

I appreciate your time.

01-10-2008, 05:47 PM
No problem, I've tried to throw together a recipe database before so I had some knowledge left (though that never got finished)

01-10-2008, 06:38 PM
I was presented with a similar problem before. Would you recommend storing the quantities as fractions? Let's say the recipe is for 3 servings and requires 1 teaspoon of vanilla. Do you store it in the database as '1/3' teaspoons of vanilla or .333333 teaspoons? You obviously have to worry about rounding if you store it as some sort of decimal number.

I just stored the default recipe in the database and calculated the quantities based on the requested_serving_size/default_serving_size ratio.

There are also some interesting conversions. For example, do you tell the user to add 6 teaspoons or 2 tablespoons. Do you convert pints, cups, etc. or just use the most "base" unit?

01-10-2008, 06:45 PM
You'd store the actual number (.333)

One can always convert to 'human readable' format afterwards. But storing it in 'machine readable' format allows you to do easy calculations with it (in the database, not php).

01-10-2008, 07:50 PM
This was posed to me as a learning exercise a few years back. The big frustration I recall having was when you store the value as decimal (.333) you end up with questionable rounding issues. For example, if you multiply .333 * 3 servings, you get .999. and you need to round it up to 1. But when you round something like 1/8 = .125 you get .13 which isn't what you want. I'm just noticing that they have added a precision parameter to round() in the years since I had this issue which is basically what I had to mimic for reasonable results.

01-10-2008, 08:13 PM
This is why the metric system makes so much more sense. No fractions. I'm sure there is a decimal to fraction algorithm out there though.