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

On Wed, 2014-12-10 at 16:56 -0800, James H. H. Lampert wrote:

On 12/10/14 3:07 PM, Monnier, Gary wrote:

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

On the other extreme, either of the two bitmapped schemes would result
in lookup tables with zero redundancy, but it would also mean that if
the total number of "starches" and/or the total number of "vegetables"
were to grow beyond any expansion space built into bitmaps in the
"protein look-up" table, or the number of "proteins" were to grow beyond
any expansion space built into bitmaps in the "starch look-up" or
"vegetable look-up" tables, then we need to modify the affected look-up
table structure to expand the overfilled bitmap. And even if they never
needed more bitmap capacity, they still might need specialized
maintenance programs: without something to break down the bitmaps, it
could be like hand-counting the cards from the infamous "butterfly
ballot" system.

When you say "bitmap" you could have some kind of set up to use a
logical XOR/AND or some such...

If you break down the three groups into a single "set" in much the same
way permissions work on linux then you could use a pattern 1,2,4 etc and
use a summing to create combinations... 3=1+2,7=1+2+4 then AND this to
the detail... so 1 AND 1 = 1, 1 AND 2 =0, 1 AND 3=1.. etc.

So the results would be say 7:7:7, 1:2:7 or some such combination.

It all gets a bit complicated, on paper, the higher the number of
potential elements and I'm not sure how a "can be selected no matter
what" could be included... binary and bitwise stuff is not my strong
point and I only really know the basics from a high level abstract
interest in raid5/6 parity on linux.

Jon