RE: Database design issue: seems really bad, yet I'm having trouble coming up with anything better

OK, so does the diagram below outline your basic needs? Read it from left to right, top to bottom for each decision set.


---------- ----------
| A single "protein" selected --->| Specify the "protein" type/source.
| ----------
| OR
---------- | ----------
| Choose a "Protein" --->| Multiple "proteins" selected --->| Specify the "protein" type/source for each selected protein.
| | ----------
Complete "meal" --->| | OR
| |
| | No "protein" selected.
| ----------
| ----------
| | A single "starch" selected --+
| | | ----------
| For each selected "protein" | OR +-->| The "starch" is compatible
| pair the "protein: with a "starch". --->| |
| | Multiple "starches" selected --->| OR
| | |
| | OR | The "starch" is not compatible.
| | ----------
| | No "starch" selected.
| ----------
|
| ----------
| | A single "vegetable" selected --+
| | | ----------
| For each selected "protein" | OR +-->| The "vegetable" is compatible
| pair the "protein" with a "vegetable". --->| |
| | Multiple "vegetable" selected ----->| OR
| | OR |
| | | The "vegetable" is not compatible.
| | No "vegetable" selected. ----------
| ----------
|
| ----------
| Pair the selected "starches" with the selected "vegetables". --->| The "vegetable" is compatible
---------- |
| OR
|
| The "vegetable" is not compatible.
----------

Regardless of what "protein", "starch" & "vegetable" represent you still have a header/detail situation.

Maybe looking at your problem from a bill of materials perspective will help. BOM is still a header/detail model with each detail possibly containing its own header/detail information. How would you present/allow creation of a BOM?




-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Wednesday, December 10, 2014 1:17 PM
To: Midrange Systems Technical Discussion
Subject: Re: Database design issue: seems really bad, yet I'm having trouble coming up with anything better

On 12/10/14 11:27 AM, Monnier, Gary wrote:

I think the header-detail model will satisfy your requirements.
Between them you can build all possible variations. My first
suggestion did assume there is only 1 protein per meal. If there are
multiple proteins for a meal as well as multiple other dishes, move
protein to the detail table.

We already know that the metaphorical (EMPHASIS ON METAPHORICAL; remember we're not really talking about food) "meal" is defined as a header record containing the "protein" selection, with two different kinds of detail records, in separate detail files, containing the "starch" and "vegetable" selections for the "meal." And this would actually be expanded to include additional detail files containing other distinct types of detail records (to continue the food metaphor, let's call them "sauce," "appetizer," "beverage," "dessert" and, well, why not "utensil"). (Reminds me of an openly sarcastic answer Judith "Miss Manners" Martin once gave in her newspaper column, in which she jokingly declared that the proper way to eat potato chips is with "a fruit knife and an oyster fork.")

The issue isn't how we store the metaphorical "meals"; it's how we store look-up tables to present users, once they've chosen a metaphorical "protein," with lists containing only the metaphorical "starches" and "vegetables" that are available with that "protein."

And the rules for what "starches" and "vegetables" go with what "protein" are absolute, to be changed only by administrators.

Now, if I actually knew how many different "proteins" were compatible with an average "starch" or "vegetable," I could conceivably have a long alphanumeric field in the "starch" and "protein" look-up record, that would contain a space-delimited list of "protein" codes (or a special "anything" code). If a "starch" or "vegetable" was available with more "protein" choices than this field had room for, but not all of them, then we'd need multiple records for that particular "starch" or "vegetable," but that could still be better than having the same "starch" or "vegetable" listed hundreds of times.

(And now that the lidocaine from my dental work is starting to wear off, and my appetite is coming back with a vengeance, I think I'll be eating my lunch very soon.)

Metaphorically Yours,
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxx> To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.