WAG...
This sounds like a customer-facing, self-service, build your own product
with custom features application ...
...having predefined configurations that the customer will be guided through
as to what is an available feature and what is not, ultimately building a
'custom' product that has already been predefined by the
manufacturer/seller.
If this is the case then perhaps the original database design that was
recommended to you would work. Since control of the final available
configurations has already been determined by the company.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Monnier, Gary
Sent: Wednesday, December 10, 2014 6:07 PM
To: Midrange Systems Technical Discussion
Subject: 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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: 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 Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
