 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / September 2007Prescriptive design rules
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 > This is a post from comp.databases.mysql: > [quoted text clipped - 45 lines] > > Evan Wrong group, sorry. Evan > This is a post from comp.databases.mysql: > [quoted text clipped - 43 lines] > If you could provide 10 prescriptive design rules to a front-end developer, > what would they be? Or just 5? 1. Learn the fundamentals 2. See 1 3. See 1 4. See 1 5. See 1 > > This is a post from comp.databases.mysql: > > [quoted text clipped - 49 lines] > 4. See 1 > 5. See 1 What are the fundamentals? Can you list 5 basic rules of thumb? Heuristics? Evan >>>This is a post from comp.databases.mysql: >>> [quoted text clipped - 54 lines] > > What are the fundamentals? Can you list 5 basic rules of thumb? Heuristics? The fundamentals are the basic principles. They are neither rules of thumb nor heuristics. What are the rules of thumb of addition? ... >>> 1. Learn the fundamentals >>> 2. See 1 [quoted text clipped - 9 lines] > > What are the rules of thumb of addition? shurely you mean rules of fingers! > > 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. >>> What are the rules of thumb of addition? >> surely you mean rules of fingers! [quoted text clipped - 10 lines] > > PS. And don't forget the binary language of moisture vaporators. Which is very similar, in most respects, to the language used to program binary load lifters. > ... > >>> [quoted text clipped - 13 lines] > > shurely you mean rules of fingers! That's only if you are adding digitally! > > ... > [quoted text clipped - 15 lines] > > That's only if you are adding digitally! I would still require 3 thumbs ;) > This is a post from comp.databases.mysql: > [quoted text clipped - 45 lines] > > 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. >>This is a post from comp.databases.mysql: >> [quoted text clipped - 51 lines] > 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. > >>This is a post from comp.databases.mysql: > >> [quoted text clipped - 53 lines] > > 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. >>>>This is a post from comp.databases.mysql: >>>> [quoted text clipped - 57 lines] > as a file system. This is where the trouble starts.That is why I asked about > 5-10 rules of thumb. Rules of thumb will not cure ignorance when what these young folks need is a solid understanding of the fundamentals. > > >>This is a post from comp.databases.mysql: > [quoted text clipped - 57 lines] > as a file system. This is where the trouble starts.That is why I asked about > 5-10 rules of thumb. Until you and your "young folks" get a grip on something as simple and fundamental as First Normal Form (see Wikipedia), then you and your programmers should probably stick to storing your data in the filesystem as whatever. > This is a post from comp.databases.mysql: > [quoted text clipped - 45 lines] > > Evan What's wrong with a table keyed by PERSON and ANIMAL with payload columns for OWNS and RATING? OWNS could be a quantity, 0 if the person doesn't own any, 1 or more if he/she owns some number of the animal. The RATING could be a string drawn from the domain "high" "medium" "low", or a number from 1-3. Animals that the person didn't rate and didn't own could be omitted. Animals that the person owned but did not rate could be given avalue to indicate "unrated", for example you could agree that the empty string (which is not the same as a null) is what's used if the person did not supply a rating. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.