Roger Baklund unknowingly asked us:
>>What would be a good way to deal with the following...
>>I have a form that has 5 checkboxes on it, lets say the
>>checkboxes are for categories, and more than one can be
>>please tell is what brochure you want
>>I have been asked to provide statistics on how many total form
>>submissions there are per month. This part seems pretty simple,
>>I just add a new record every time the form is sent.
>>They also want to know stats on which categories were picked as
>>well. I don't know if I should create one table to store just
>>the fact that a form has been posted, and then another to store
>>the 5 above values.
>>I don't see the 5 categories being changed, so I could create 5
>>fields in one table, and tally them that way, or I could create
>>one field and put the actual value in that field and tally them
>>Any suggestions are appreciated.
> Consider the SET column type:
Yes, SET seems a good way, as you're going to allow multiple choices in
But for a couple of reasons, SET is not recommend.
1. It introduces fragmentation, and indexes are pretty hard.
2. It defies the universal rule of a normalised table:
You cannot, no matter what, and should not, store more than one value in
a single cell of a database table.
Even if you did, it is going to be really hard later on to change the
names of the SETS (this would contradict with the user's choice), and is
going to be still harder to add another choice to your list.
The best I would recommend, though it takes up more space in the table,
is to have a separate column in another table with a one-to-one join,
and each column as each choice, and each column with the ENUM type of
Think before you choose, for you don't want to be sorry later.
[ Rajesh Kumar ]
Meet the guy at http://www.meetRajesh.com/