mark | r wrote on 20 jun 2005 in
microsoft.public.inetserver.asp.general:
Im creating a food site where registered users can set a long list of
'dislikes' from a menu that can be added to, with the aim of the site
being searchable for things that DONT MATCH the 'dislikes' of a user -
dislikes would be in categories i.e. Fruit / Tomatos / Diced (because
i like tomato sauce, but not tomatos so id be able to select
everything but sauce and puree)
BTW im doing it this way because fussy eaters like me can list loads
of what they dont like but not much of what we do - the idea is id be
able to be shown recipes for meals that i will like.
anyone suggest the best format for structuring the tables in the
database for this project, because every avenue i try gets overcomplex
really quickly, or becomes un expandable.
There is no "best" way, Mark.
It depends on the way of programming you are familiar or happy with.
============================
I would:
Make a new 2 column DislikeTbl table of all dislikes, be it group or
individual dislikes.
dislikeID*, dislikeName
All products are coded in the productTbl table with say a maximum of 3
productDislikes.
[3 fields additional]
Make a new 3 column UserDislikeTbl table with
UserDislikeID*, userID, dislikeID, weight
[eight: 2 heavy, 1 slight, -1 like, -2 love, 0 off]
So any user can have a unlimited number of dislikes, each with it's
weight. [I suppose most will have no dislikes at all, but others have, so
the last table won't grow too large]
No dislikes are stored in the userTbl itself.
Tomato sauce will have 3 productDislikes:
Tomatos general & Tomato sauce specific, vegetable conserve.
Fresh tomato's 3:
Tomatos general & fresh Tomato specific, fresh vegetables.
You could have:
+1 Tomatos general
-2 Tomato sauce specific
-1 Tomato Ketchup specific
the SQL string will test for entries in UserDislikeTbl and you compute
the resultingDislikeValue being positive or not.
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)
