Evan Keel wrote:
> "Evan Keel" <evankeel_at_sbcglobal.net> wrote in message
> news:EbnBi.1216$3Y1.852_at_newssvr17.news.prodigy.net...
>
>>This is a post from comp.databases.mysql:
>>
>><<let's say I want to ask a survey question, with checkboxes:
>>
>>What animals do you like?
>>[] giraffe
>>[] elephant
>>[] donkey
>>...
>>
>>I'd possibly create a single column named "like" and store each
>>response as a comma delimited string:
>>giraffe,donkey
>>elephant,donkey
>>etc
>>
>>
>>But further, let's say I have a question with checkboxes and also
>>radio buttons:
>>
>>Please select which animals you own, and tell us how much you like
>>each:
>>
>>[] cat () low () medium () high
>>[] dog () low () medium () high
>>[] rat () low () medium () high
>>...
>>
>>What's the best table design to store that? E.g., I could have a
>>column named "own" and another column named "rate". Or I could have a
>>column named "cat" which might contain:
>>yes,low
>>
>>and another column named "dog" which might contain:
>>no
>>
>>and another column named "rat" which might contain:
>>yes,high
>>
>>etc. But neither of those seems quite right to me.
>>
>>I'm obviously thinking of using one flat table for the whole survey,
>>is that a very wrong thing to do? I'm assuming that using a flat table
>>will naturally make it easier to export in spreadsheet format. I'm
>>also not concerned about the memory usage of a flat file.>>
>>
>>If you could provide 10 prescriptive design rules to a front-end
>
> developer,
>
>>what would they be? Or just 5?
>>
>>Evan
>>
>
> You guys are so smug and clever. I was looking for real examples: When
> nulls are ok. When 2 tables have the same key.
Never. And when they do.
Received on Thu Aug 30 2007 - 21:41:02 CDT
