× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.