Patricia,

It would be pretty daunting to overhaul the DB structure. It would be more conventional to use an integer for "ingkey" which is currently text and then have yet another table that linked the "ingkey" (conventionalized ingredient name) and number, but that would add another layer of joins and complexity without necessarily bringing any substantial efficiency gains.

Storing only an "ingredient id" and "recipe id" per ingredient doesn't work because ingredient "text" in recipes often includes recipe-specific, useful information, such as preparation information and so on. You have to remember that Gourmet is designed to make it as easy as possible to work with actual recipes, rather than being designed to turn recipes into the kind of database a programmer would necessarily fashion from scratch. The way it works out, someone who doesn't care about nutritional information or particularly care about getting their shopping lists perfect can use Gourmet without ever having to think about the "ingkey" (standardized ingredient name). Gourmet then adds the "ingkey" as a layer so that these more data-centric tasks (nutritional info, good shopping lists, etc.) can be layered on over the standard, messy representations of recipes.

So we end up having...

Recipes
- Info
- ID

Ingredients (your "Ingredients per recipe" tale)
- Recipe ID
- Amount
- Unit
- Description (name + prep info, etc.)
- ingredient key (unique text identifier, used for shopping list and for nutritional information, etc. -- this may well end up being identical to the "description" text if the user doesn't want to bother improving it and in fact this is invisible to the user if they don't activate one of the plugins that makes use of it)

Then, as equivalent to your "Ingredients" table, we have a couple of different tables

Keylookup_table - this table actually just facilitates faster search when trying to match a new key to an ingredient. Note that the "count" here is part of a way of prioritizing search results -- it is possible for the same text to "key" to a different "ingkey" in different contexts -- this is because recipes are often imprecise and a user generating a shopping list may specify that they mean different things when two different recipes call for an ingredient like "pepper" or "flour."

- text
- ingkey
- count

and

- word
- ingkey
- count

Nutritional Aliases 
- ingkey,
- USDA ndbno (this links to all nutritional info)

Not simple, I know, but I hope that makes some more sense of things.

Tom




On Wed, Feb 8, 2012 at 1:12 PM, Patricia Dousseau <pdousseau@gmail.com> wrote:
I've found defaults file. Thanks.

What I mean about the tables:

A recipe can have many ingredients, and a ingredient can be in many recipes. It would better if we have three tables:
- ingredients
- recipe
- ingredients_recipe

So we could have something like this:

Recipe_table
id_recipe
name_recipe
...

Ingredient_table
id_ingredient
name_ingredient
...

Ingredients_per_recipe_table
id_ingredient
id_recipe
amount
unit
optional
...

So if we have a common ingredient, like salt, pepper, sugar, it will appear only one time in ingredients table. It would be much better to search recipes through ingredients, it wouldn't be redundant, it would spend less storage space and tables would be normalized.

The way it is done gets really hard to get ingredients that are not repeated, because ingredients_table has many instances of the same item. 

Another thing I've found strange is that shopcatsorder doesn't have a foreign key, like many other tables. 
I can make another design for the tables, and try to implement. What do you think? Do you think it would be too complicated to change the actual design? Or would I have to change only the db.py?

Thanks, and sorry if I'm being much abusive.

2012/2/7 Thomas Mills Hinkle <Thomas_Hinkle@alumni.brown.edu>
On Tue, Feb 7, 2012 at 6:35 PM, Patricia Dousseau <pdousseau@gmail.com> wrote:
I downloaded Gourmet and I loved it, it has wonderful features! It's helping me a lot, I'll use it as my official recipe book.

I wanted to help the project, so I downloaded the source code to take a look. I'd like to imple Doubts about implementation ment a plugin to list and set the price for ingredients, so that people could know the cost of any given recipe. I ended up with some doubts, and I'd be very grateful if you could help me:

Is the default.py file used anywhere? I looked for references in the code but I couldn't find anything.


Yes, the defaults are used frequently -- look for import defaults.defaults just about anywhere in the code. The defaults directory is basically set up for localization that can not be done with standard/simple localization tools -- unit conversions, categories, common ingredients, etc. -- things that go beyond simple translation.
 
Why aren't the recipe table and the ingredients table n:n? Very common ingredientes like salt end up with numerous entries. I also found strange that the the foreign key was placed in the ingredients table, instead of the recipe table.


I'm not sure what you mean, I'm afraid.

There is a table for recipes, each row of which includes information about a recipe. Then there is a table for ingredients, each row of which includes information about a particular ingredient, including the recipe it is part of.

For what you're working on, you'd want to create a new table which worked off of the ingkey and keyed it to a price. You can use the shopping code as a model, as that does the same thing (keying each ingkey to a shopping category).
 
Congratulations and thank you very much for making Gourmet available. 

No problem. Glad you're interested in playing around with it.

Tom
 
Have a great week, 
Patricia


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel




------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel