Normalizing a database schema -



Normalizing a database schema -

i trying design database schema accurately represents survey, questions , responses. here requirements database:

the db needs accommodate various surveys (each may have unique questions or may same). each question can either have responses open ended or selected list. selected list can have 0, one, or more responses or may allow 1 response. problem having in normalizing question, response, , possible choices of responses per question. have far:

the way designed survey table hold multiple surveys. each survey can have multiple question. each survey can filled out multiple respondents (or same). questions can have 0, 1, or more pre-defined responses (think multiple selection example). these responses may not have multiple selection selections but, instead might open ended responses. so, table "possible_responses" might this:

name questionid illustration question reddish 1 favorite color bluish 1 favorite color greenish 1 favorite color pizza 2 favorite nutrient apple 2 favorite nutrient steak 2 favorite nutrient

then, answers table might this:

id response questionid illustration question 1 1 1 favorite color 2 1 2 favorite nutrient 3 "subjective respones" 3 subjective quest.

i trace question questions table determine if response should open ended or closed.

although might work, doesn't sense normalized me. have suggestions on how best normalize schema?

as philipxy commented, describe possible problems or concerns may have.

you defined 1 relationship you've not yet drawn line (do so).

tables should named in singular. you’ve mixed singular, plural.

indeed, different answers. may not representing when question allowed have open-ended response , when not. in other words, open-ended response is possible response, should represented "possible_response". represent either (a) having boolean column "open_ended_" on "possible_response" table, or (b) have row in table special value such "open-ended". in either case, "answer" table kid of "possible_response" table. if "answer" kid of "possible_response", answer.response column used when belongs "possible_response" marked open-ended. answer.response column should have name changed "response" "open_ended_response_".

"name" not best name column in "possible_response".

the word "answer" not end in 'e'.

what mean 1st sentence of 2nd paragraph? mean variations of survey may given different participants? if so, there should "variation" table.

usually find helpful draw kid tables lower on page (where feasible).

tips on naming: (a) maximum portability across sql database implementations, utilize lowercase in names (along separation underscores did). (b) sql spec promises never utilize trailing underscore. adding trailing underscore prevent naming collision key/reserved words. means "possible_response_" rather "possible_responses".

database-design database-schema normalization database-normalization

Comments

Popular posts from this blog

php - Android app custom user registration and login with cookie using facebook sdk -

django - Access session in user model .save() -

php - .htaccess Multiple Rewrite Rules / Prioritizing -