recipe database using "kitchen inventory"

[hcaulfield]

Hi everyone...

This is my first post to the forum, and although I am listed as a "beginner" in my profile, I'd prefer to call myself a "complete noob." I am working with the trial version of Filemaker 8 and am trying to put together a test database to help me learn the program..

I use Salesforce.com and see many parallels to FileMaker... I have spent quite a bit of time watching some tutorial demos online and feel like I have a general grasp enough to make something like a "DVD collection database" or something simple...

I'd like to spend this week developing a recipe database that would allow me to generate a shopping list based on recipe choices and also based on what I have in my "kitchen inventory."

The way I see it, I will need three databases. The first one will be the recipe database. The second will be be my "kitchen inventory" and the third will be a "grocery store inventory."

I have some questions, though. Is it best to have "kitchen" and "grocery store" seperate? Is it possible to use one database for the products and simply denote how much of each product that I have in my kitchen?

Also - does anyone have any idea how I can deal with the problem of multiple measurements? For example, if I buy a gallon of milk, a recipe may call for three cups of milk...

am I going to have to implement some sort of conversion script or something to allow me to work between these different measurements?

OK.. to sum it up, what I'd like to do is enter 10 or 15 recipes... then, I'd like to be able to enter everything that I have in my kitchen into the database....

So, say I select "pasta alfredo" I'd like my database to check to see if I have enough pasta in my kitchen. If I do, it won't add it to the shopping list. If I don't, I'd want it on my shopping list so I can get it at the store.

Do any of you have any suggestions?? I'd really appreciate some help while I get my feet wet with FileMaker.

Thanks everyone!

[robbstuck]

Umm, wow.

You really jump in with both feet don't you?

If you are really serious about this project, may I suggest attaching a bar code scanner and seeing if you can obtain a recent copy of the UPC datalist.

That way you can auto scan the items into your database as you put them away into your pantry. The UPC data will automatically provide the initial quantity/weight of the product.

You will also need a connected scale, so as you use the product, wave it before the scanner and then weigh it, you automatically subtract the amount used from your database. You'll need to calculate the density of each of your products so that you can just use weight measurement rather than trying to measure then enter volume measurements as you cook. (note this won't work with items that absorb moisture such as flour, or items that can evaporate or condense as they are stored)

Yes, you will need many conversion functions. The US penchant for maintaining the ancient British King's measurement system also means you have much more complicated work set out for yourself. Note the British long ago abandoned this measurement system in favor of something that is much easier to do conversions with. I'd recommend converting everything to metric behind the scenes. And you'll create an international product without excess work.

A touch screen mounted in the kitchen, would allow you to select and update the data without getting ingredients into your keyboard as you cook.

Add nutritional information about the recipies and...

Viola! you have a nutritionist in a box!

There have been many of these types of nutritional tracking systems created over the years. Most usually fail due to the extreme amount of upkeep the database requires to be functional. If you aren't running a professional kitchen it usually isn't feasible. Search for nutritionist or nutritional expert system and you should find some examples and many more ideas that would make your system even more usable. There used to be some open source attempts. I haven't looked for them in a long while.

I don't want to dissuade you from your goal, but if you really are a newbie, you might want to try making a couple of those "DVD collection databases" before heading straight into something this incredibly complicated.

But if you are planning to make this your life's work, well then...

I want to help beta test your product when you start getting something usable.

This sort of thing has always been a sort of dream for me too. But the implementation is still a little beyond the reach of your average kitchen cook.

The technology is coming down to affordable levels. Computers are moving into the kitchen. But maintaining UPC data will be tough. Retail store chains pay dearly for UPC datalists that are constantly going out of date.

I pitched this idea to Whirlpool, the parent of KitchenAid. It got slight traction but was ultimately rejected due to the upkeep and discipline it would require in practice. Maybe when every product has a transponder in it and containers can communicate the level of their contents this will become feasible.

[Oldfogey]

I'm sure there are worse projects to start with than a simple Recipe database but not many. As for your rather complex plan, LOL!

Could I suggest a simple shopping list preparer, with info about where you buy items and maybe how much for what quantities? Add a map of your supermarket layout for fun.

Seriously, start really simple and then add complications. This is not a good way to do bigger projects but you sure learn a lot very quickly.

There are a few threads here about recipe DBs. None of them are very optimistic.

[Fenton]

I would commend hcaulfield on his/her critical thinking, seeing the basic entities involved, and the basic problem of conversion. I would agree with the others however that complete implementation of a recipe/inventory/shopping solution is not ideal as a 1st database, mostly because of its complexity. It might be good if you've got the time, ability and determination to succeed. It might be more like a month than a week :-|

I know because I did it. Way back in FileMaker 4. I was at the intermediate skill level, not a raw beginner. I think it took a bit more than a week. It would be easier now, because of tools in FileMaker 8, much easier because I'm past intermediate now (somewhat). It would still take a while.

It's a good project for intermediate developers because:

1. It relies heavily on relationships and related tables.

2. The conversion issue can use an auto-enter calculation(s) with a related conversion factors table.

3. Inventory depletion requires a "must run" script, with control of the interface.

3. It shows how "reference" tables and "data entry" tables interact.

4. The basic objects and concepts are familiar.

5. It is harder than it looks, despite #4 -]

For a starter, you could just make the tables (only 1 file), and see how far you get.

1. Recipe Dishes table

    1. a. Ingredients table (child of 1)

        Quantity

        Measurement type

        Conversion (Tsp to TB to Cup, etc., to produce one "standard" to use for conversion of ingredient)

2. Foods table (related to everyone, more or less)

    Any food you want to have on hand

    Quantity on hand

    Threshold (when to put on shopping list; must be above recipe requirement or can't make it)

    Conversion factor; recipe measument vs. store measurement (12 oz. box, 1 lb can, etc.)

        I think I'd just have 1 store measurement for starters (or just OZ, Qt or LB); so there's 1 conversion factor

3. Meals Dishes table

    Dishes prepared, with # of people

    This is the main data entry, after reference tables are done

    Script to loop through each ingredient and decrement Quantity on hand (after conversion using factor)

4. Opt. Meals table

    Breakfast, Lunch, Dinner, Snacks (parent to Dishes)

Something like that. For a look at my messy old files (which would need to be completely rebuilt in 8):

http://www.fmforums.com/forum/attachment.php?attid/6548/

Read the whole thread of the above:

http://www.fmforums.com/forum/showtopic.php?tid/174281/post/195607/hl/Recipe+Fenton/#195607

[Siri]

Hi

I had the same idea as you (making a recipe database) as I want to graduate to an inventory system.

I created a table for the recipe and a subtable with quantity, unit and ingredient name. Then a unit database related to the unit ID in the recipe ingredient subtable. For each unit I had a name and a conversion factor to mL or mg.

Back in the recipe screen I created a field for original number of portions and a "required portions"

In recipe ingredient subtable, I created a field for conversion unit (ID) that you could choose from a dropdown names from the unit table and then used a simple calculation to fill in the converted quantity of units based on the metric amount of original units and required portions.

So this brings me to the shopping list (I haven't added a way to subtract what I have yet), but I'm working on a yes/no field in the recipe table for whether I want to buy the ingredients for that recipe (for the required number of portions). I intend to copy that yes/or no to each ingredient in that recipe and then sum up each ingredient for each yes ingredient thus creating a shopping list.

I'll email you what I have if you let me know you want it. I'm at siriuslea@hotmaildotcom.

Let me know if you're still working on it.

Siri

Edited August 26, 2006 by Guest