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

Consider this scenario:

We have three sets of items. To avoid discussing the real-world
situation, I'll use a food analogy, and call them protein, starch, and
vegetable.

We have perhaps as many as 300 distinct protein items (to which others
may be added in the future), some 60 starch items (to which others may
be added in the future), and some 80 vegetable items (once again, to
which others may be added in the future). A complete meal includes a
protein, an arbitrary number of starches, and an arbitrary number of
vegetables.

We always select the protein first. Each protein has its own subset of
compatible starches and vegetables, e.g., if the protein is prime rib,
10 oz cut, then the available starches would include Yorkshire pudding,
mashed potatoes, and baked potato, and the available vegetables would
include creamed spinach and creamed corn, while if the protein is roast
turkey, 8 oz, then the starches might be dressing and mashed potatoes,
and the vegetables might be creamed corn, Brussels sprouts, and carrots.

Now, the solution that's been presented to me is for the protein file to
have a record for every protein, the starch file to have a record for
every valid combination of one protein and one starch, and the vegetable
file to have a record for every valid combination of one protein and one
vegetable.

Something about this seems wrong. Mainly because it would produce so
many starch and vegetable records, repeating any given starch or
vegetable for every protein with which it's a valid combination.

Yet I'm having trouble coming up with anything better. Any suggestions?

--
JHHL