×
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.
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
midrange.com
