![]() | |
#11
| |||
| |||
|
|
Evan Keel wrote: "Evan Keel" <evankeel (AT) sbcglobal (DOT) net> wrote in message news:EbnBi.1216$3Y1.852 (AT) newssvr17 (DOT) 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. |
#12
| |||
| |||
|
|
"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote in message news:46d77f70$0$4022$9a566e8b (AT) news (DOT) aliant.net... Evan Keel wrote: "Evan Keel" <evankeel (AT) sbcglobal (DOT) net> wrote in message news:EbnBi.1216$3Y1.852 (AT) newssvr17 (DOT) 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. I am working with many PHP programmers. These young folks view the DBMS as a file system. This is where the trouble starts.That is why I asked about 5-10 rules of thumb. |
#13
| |||
| |||
|
|
On Aug 29, 7:54 pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote: Bob Badour wrote: What are the rules of thumb of addition? surely you mean rules of fingers! It depends. People use base ten, so they need all their fingers, including the thumbs, to do addition. However computers internally use only the binary language of ones and zeroes, and so can get by with just thumbs. Also, teenagers and their texting these days! Email is for old people they say. Marshall PS. And don't forget the binary language of moisture vaporators. |
#14
| |||
| |||
|
|
"Bob Badour" <bbad... (AT) pei (DOT) sympatico.ca> wrote in message news:46d77f70$0$4022$9a566e8b (AT) news (DOT) aliant.net... Evan Keel wrote: "Evan Keel" <evank... (AT) sbcglobal (DOT) net> wrote in message news:EbnBi.1216$3Y1.852 (AT) newssvr17 (DOT) 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. I am working with many PHP programmers. These young folks view the DBMS as a file system. This is where the trouble starts.That is why I asked about 5-10 rules of thumb. |
![]() |
| Thread Tools | |
| Display Modes | |
| |