posted
Of course, anyone else is welcome to comment as well. Here's the ERD.
The group and user tables are part of mambo. The cookbook table is really just to allow different recipe sets with different user rights. I intend to only use one cookbook at the site.
Viewing rights will be assigned based on mambo groups by cookbook. This is limited, but will suffice until the next version of Mambo comes out.
Editing rights will be defined as follows: Submit recipes (which also allows editing of recipes submitted by the user). Edit recipes (which allows editing of any user's recipes). Admin - basically a God mode, which will ultimately be used to manage the back end.
Navigation will be through groups and categories.
A group would be nationality, for example, and choices might be American, Tex-Mex, Mexican, Chinese, French, Italian, etc. Each group will have the option to allow only 1 choice or multiple choices.
Each recipe can be categorized in as many groups as desired: Type of Dish, Nationality, Main Ingredient, etc. I envision a simple checkbox or radio button schema to allow selection of all categories on one screen.
Browsing will be through groups, then categories. It could span multiple cookbooks (assuming the user has rights to multiple cookbooks). Ordering can be assigned to any group, category, or recipe. Sorting will be based first on ordering, then on title.
I can admin this from the back end, so to start I'm just going to work on a front end to browse and add/edit recipes.
posted
I'd suggest creating a separate ingredients table and using a linking table between ingredient and recipe along with amount. That'd give you and your users a lot more control over things like ingredient searches edit: and possible substitutions.
Oh and in the recipecategory table diagram, you've got your unique index 1 displayed twice. Maybe that just has a meaning I'm not familiar with.
quote:I'd suggest creating a separate ingredients table and using a linking table between ingredient and recipe along with amount. That'd give you and your users a lot more control over things like ingredient searches.
I thought of that - it was my first inclination, in fact. It would certainly help with adjusting recipes (changing 4 servings to 6, etc.). It would also make formatting a little easier, I think.
As for searching, I'm not sure how much it helps, because we've pretty much got to use some kind of full-text searching anyway. Unless, of course, I made an ingredients table and an ingredients to recipe linking table (which would have the measurements). The payoff there would be huge, but the complexity whenever a user needs to add an ingredient not in the DB is very high.
The downsides are in UI complexity/usability trade offs and initial development time. If I was developing this back at my company, I'd insist on it.
What do people think: how useful is a scale up/scale down feature?
quote:Oh and in the recipecategory table diagram, you've got your unique index 1 displayed twice. Maybe that just has a meaning I'm not familiar with.
That's an artifact of Visio using an Access driver to make an ERD for a MySQL database. The little abbreviations next to the field names can be ignored - the important thing is that the PK fields are above the line, the other fields below.
quote:What I'd really like to see is a context-free way of describing instructions, so the computer could actually parse recipies.
Oh, some kind of symbolic language. Each container would accept input (1/3 cup flour, 1 tsp. baking powder, etc.) and a combination method (fold, stir, whisk) or an operation (bake at 325, simmer, boil, cool) and a time limit.
Each could be defined and then recipes could be meaningfully constructed. It'd be step 1 to making a cooking robot!
posted
Jeez, I didn't even thinking of the scaling issue. I'd do it, although you're right about the increased overhead with people adding new ingredients. I don't actually think it'd be that big a deal though, unless you were going to enforce stricter duplication constraints than I think you need. Just get the people to enter the ingredients in a list instead of a textbox, do an exact lookup and if you don't get a match insert it.
adam, All you need to do to link the ingredients to the recipes is to have a lining table with recipe_ID, ingredient_ID, number, and measurement (e.g. tsp. or cup or whatever).
Posts: 10177 | Registered: Apr 2001
| IP: Logged |
posted
That's true - I've written cleanup routines before for similar situations that automatically replace all references to "buttr" with butter.
What I really hate is the UI - you have to start with some number of ingredients, and have a button to increase it. It's just tacky to my UI sensibilities. Sometimes I miss fat clients.
A drop down list of ingredients would be cool, too, but that really gets difficult to manage on the web once the list gets long.
posted
If you're willing to countenance some extra work on the backend side, you could still do this with people entering the ingredients into a text box. You'd have to make sure that they followed some sort of standard and then you could extract the relevant information.
If it's going to look like:
1 cup sugar 1 tsp. salt
it should be too hard to write like a regular expression that could match the possibilities. The big problem there is how do you handle things were it doesn't parse correctly.
Posts: 10177 | Registered: Apr 2001
| IP: Logged |
posted
You can always use js to to a sort of type ahead find. Its pretty slick, and really beats a drop down.
Posts: 1621 | Registered: Oct 2001
| IP: Logged |
posted
I work in a kitchen, it IS fun. I got to use the big heavy duty mixer thing last week. It's like playing with power tools.
And as a side note, it's very confusing to read a thread when adam posts anywhere, because my real name is Adam, and I always think someone is addressing me.
Posts: 21898 | Registered: Nov 2004
| IP: Logged |
Printer-friendly view of this topic
![[Smile]](smile.gif)
![[Big Grin]](biggrin.gif)
![[No No]](graemlins/nono.gif)
