Your favorite database idea

ITP: Personal Rant

Well, if we assume that flour has same density, we can derive the volume from weight or vice versa as long we know the density and the density doesn't vary significantly between different flours (and even if they did, we can make them a separate record).

We would not be having this problem if Americans stopped embracing this idiotic system of measurements. Trying to do this on the left side of the atlantic would involve a separate table with conversions because there is no simple way of doing conversions between fl oz/cups/pints/quarts/gallons/oz/lbs/etc. If we embraced the metric system this whole issue would not exist. I'm tired of hearing Americans saying that the metric system is hard to figure out... if you can't multiply/divide by 10, you should go get a gun from your stockpile, go out back, and ... nvmnd.

Sorry, Now to be productive: If you're using the "convert volume to mass" method, it might not be a bad idea to have a table that keeps track of how much you actually managed to use out of each package (say flour for this example). So next time that you put flour in your pantry, the system examines how much each past bag has yielded, and averages those quantities. It then uses the average as an expected quantity within the bag of flour. You could possibly get away with not doing any mass to volume conversions if you spent some time doing data collection.
 
Last edited by a moderator:
Man I just love being called idiotic. ;) I chose to have to learn what they taught me in school, why don't they reschool all of us stupid Americans.
 
Not a bad idea about the flour alktrigger, and I don't see where any of us were talking about conversions between metric and nonmetric. Did I miss something?
 
I was calling the system idiotic not you... unless you can't multiply/divide by 10.

The reason I brought up the metric system is because in cooking, flour and other measurements are made in mass not volume i.e. 500g of flour instead of 1 cup of flour. If we were using this system, the whole issue of the volume-mass conversion would not be neccesary. But unfortunately for us, we're stuck with this avoidable problem. Just another thing that makes metric system>> American standard system.

-background info on me: Raised in South AFrica (Metric) moved to US of A (Standard). I've had the opportunity to see the miracles of metric system at work and the failures of the American system.
 
hmmm, a little off track, but you would have to change the worldview of an entire nation who thinks a certain way, recipes, every item in a grocery store, scales, gosh so many things, I don't think that change will ever happen. I guess there are plus and minuses to every country. And yes, lol, I can divide by ten, but please don't ask me to do stuff in the metric system, because I would still be lost.... My background is in accounting. also, grew up in Texas, lived in CT for 14 years, moved back to Texas, all standard. I know you a were not calling me personally idiotic, I was kind of joking. :)
 
Off track maybe.

Another suggestion for incorporation into the pantry DB: if you can examine the frequency that you purchase some items that are harder to keep track of (milk and juice usage for example) you could create a similar database as I mentioned before, so that when you have the DB compile a grocery list, it can prompt you to check the amount of product that is left, assuming it had determined that you should be low at that time.
 
Skipping back into the past here a little:

I would rather some kind of conversion table, as I do not have a scale, nor do I have room in my tiny tiny kitchen to store one. But that would be kind of hard, you would have to have weight factors for each item that gets used that way.
But you have a barcode reader ready to go? If you are going to implement this database as a whole, would you not make room for a computer that is hidden near the pantry, and a dock for the barcode scanner? Why not add a neatly hidden digital scale in the countertop, something that could serve multiple purposes? maybe even go as far as to get one of those barcode scanners/scales they have at grocery stores. I just feel if you're putting the effort in to make this database effectively run your kitchen, you might as well go all the way and do it right.

just my $0.02
 
I was calling the system idiotic not you... unless you can't multiply/divide by 10.

The reason I brought up the metric system is because in cooking, flour and other measurements are made in mass not volume i.e. 500g of flour instead of 1 cup of flour. If we were using this system, the whole issue of the volume-mass conversion would not be neccesary. But unfortunately for us, we're stuck with this avoidable problem. Just another thing that makes metric system>> American standard system.

-background info on me: Raised in South AFrica (Metric) moved to US of A (Standard). I've had the opportunity to see the miracles of metric system at work and the failures of the American system.

Agree 100%

By the way, how tall are you? - Aus went metric back in the 70's and this is still the one metric my brain doesn't handle, I'm still 6 feet
 
This is supposed to be my dream database, and I would like to use it as my kitchen is now (I rent a tiny cottage).... I don't have a barcode scanner now, I would have to purchase one, but on the whole I think both the scale and the barcode scanner is great funtionality for the database to have for growing purposes, but would need to be able to function without those things too.
 
Agree 100%

By the way, how tall are you? - Aus went metric back in the 70's and this is still the one metric my brain doesn't handle, I'm still 6 feet

I'm not used to estimating lengths in metric anymore, easiest way to convert 1m ~ 1 yard (36 inches ~ 39inches) but this is only applicable to anything within 4-5 yards. If you're thinking in inches, to go to cm is just to multiply by 2.5 cm/in (actual conversion is 2.54cm/in). So for me (and apparently you) being 6' tall, it's 2m - (6" ~ 15 cm) = 1.85m which is close to google's conversion (6 feet = 1.8288 meters). But I rarely use meters in daily life, only in calculations.

here we are, going off topic again.
 
OK, Here is a start, I have started thinking about forms and queries, but haven't had time to work on any yet.... This is just handling the recipe part of it, so far.
 

Attachments

Great Start! Time to raise the bar.

New Features:
Users and Groups (Limit certain recipes to certain groups or users.) (Great for children or guests)
Ingredient UPC/EAN Codes (The ability to assign more than one UPC/EAN code to the same general product and vis-versa)
(A 5lb bag of white flour could possibly have hundreds of different UPC/EANs, but for most purposes; A 5lb bag of white flour is a 5lb bag of white flour)
Recipe Table Structure (A Recipe now consists of the following parts; Recipe Details, Ingredients, Utensils, and Instructions)
 

Attachments

Last edited:
I would concentrate on the Ingredients first - this will drive everything else. Using flour as an example (& I will metrics)
id
Ingredient.......Flour
Unit...............gram......This is what you use in recipes
Packsize.........2 kilo's....Do we need conversion table (2000gms)
Reorder..........200gms...Do you want to run out before you get more?
BarCode.........scanner's might be a bit much for home.
 
I would concentrate on the Ingredients first - this will drive everything else. Using flour as an example (& I will metrics)
id
Ingredient.......Flour
Unit...............gram......This is what you use in recipes
Packsize.........2 kilo's....Do we need conversion table (2000gms)
Reorder..........200gms...Do you want to run out before you get more?
BarCode.........scanner's might be a bit much for home.

For 'Reorder' would we want that to be a static value for each ingredient or calculate on the fly based on a global percentage? Like a global reorder threshold?
Pros: A single setting for the user
Cons: Some ingredients might not apply in that way. Can you think of any that might not work?
 
I don't know what you mean by global? Do you mean throughout the entire ingredients list one setting for reorder level? As a person who has done some production planning it would be best to set the level for each different ingredient.
 
For 'Reorder' would we want that to be a static value for each ingredient or calculate on the fly based on a global percentage? Like a global reorder threshold?
Pros: A single setting for the user
Cons: Some ingredients might not apply in that way. Can you think of any that might not work?

Initially, thinking per ingredient, but as it is only a reorder point, not an actual quantity, if you had to reorder when you get down to 5.4 eggs, so what? Your not going to order 12.6 eggs are you

So I think a global setting might probably work - Unless product freshness becomes an issue eg for a certain ingredient, down to the last 5% (global reorder point) still might last 6 months (it only gets used sparingly) so having an extra packet in stock just goes off.

More thought required. Maybe both options available?
 
OK, lets get clever, new field & table required:

id
Ingredient.......Flour
Unit...............gram......This is what you use in recipes
Packsize.........2 kilo's....Do we need conversion table (2000gms)
Reorder..........200gms...Do you want to run out before you get more?
BarCode.........scanner's might be a bit much for home.
Class.............Vegetable/meat/spices etc

Global Reorder setting per Ingredient class based on shopping frequency.

eg Vegetables - daily, meat -weekly, spices -monthly
 
Madames et monsuers, I submit for you dining please:

Need help on Units in the recipe dissappearing and next record goes to ingredient, not next recipe - any help appreciated
 

Attachments

On your form (2frmRecipe) instead of putting the ingredient info in the detail section as individual controls, you need to make a subform and put the ingredient controls there.
 
I tried using a subform but had big problems with getting the query to recognise which ingredient was selected - [Forms]![recipeSubform]![ingredient] doesn't work (for me anyway) when the Ingredient is in a subform.

Your technique is the usual way I would approach this, but this one is driving me nuts!
 

Users who are viewing this thread

Back
Top Bottom