> wants and another for foods they don't want. You could have the "all
> foods" Boolean flag in the people table and modify the SP to add all
> foods except the ones listed in the " don't want" table. Only foods in
> the "want" table are valid. The second intersection table would only be
> used for people with "all foods" to specify foods they don't want.
>
See? I told you this was an interesting little problem to think about :)
I think when it comes to two intersection tables, I would prefer a single
intersection table, but one which has an additional boolean field of, say,
JustHatesIt_YN
PersonID
FoodID
JustHatesIt_YN (default FALSE)
My reasoning would be that one cannot have both a like and a dislike for the
same food, as two interesection tables would allow. (I use that a lot on
things that are clearly boolean, such as a user security Permission table to
specifically disallow someone from being assigned a given Permission even if
his Roles membership allows it)
(Obviously this is quite different than suddenly allowing a Person to "rate"
a Food on some sort of a scale as to how they like it, though it still seems
like a single intersection table could be used with that Boolean field
simply changed to one to accomodate the food rating for that given
Person --- but I digress)
Although the idea you proposed is an interesting what-if, Tom, it seems to
negate the whole idea behind BigBob liking *all* foods. He can't really
like all foods whilst disliking some foods. It would be like "being a little
bit pregnant"
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
