Re: storing survey answers of different data types

On Apr 23, 10:32 am, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> wrote:

<snip>

Bob, thanks for your informative responses. My Pascal books are on
their way, hopefully in the next few weeks I can get up to speed on
this. :)

I would avoid NULL if possible.

How could I know whether a user had answered a question or not? If a
user is interrupted while filling out a survey, we'd like them to be
able to resume where they left off. How could I meet these goals


So using DDL in day-to-day operations ( adding a questionnaire ) are
legal moves in this situation? I can go along with that.

To be fair, it may present some concurrency issues depending on the
backend and the frequency with which questionnaires and versions of
questionnaires get created.

(You realize each version needs its own table. Right?)

I think I do. Isn't it true, in this scenario, that a 'version' is a
different questionnaire, for practical purposes? That's my current
understanding.


Am I following you here? Convenient, but not necessary?

Not necessary in the dbms. It could just as easily be in php, html, a
smarty template, etc. Where it belongs depends on all of your requirements.

It seems like my technical understanding of RDBMS theory is lacking
here. I understand that I can store the questions anywhere -- on
paper, in another digital format, or even in a relational database. To
me, then, it's a matter of convenience that the questions would be
stored in the database -- I get one stop shopping when generating a
web page or a report. But in rdbms terms, it's not necessary, where
'necessary' has a strict jargon definition.

Can you maybe provide me a start in understanding what is necessary in
the database sense? I'm having trouble understanding why, say, the
answers to the questions are necessary to be in the database ( maybe
they aren't), while the questions themselves wouldn't necessarily be.


Suppose I wanted to compile a report of the responses. Am I to look up
the questions from documentation, type them in, and produce the
report? Why not store them electronically? In a database? Why not
store them in the same database, in the same questionnaire where they
originated? Why not put them right where I need them, so I don't need
to refer to documentation when I make a report, but instead I can just
throw another column into the query?

All excellent questions. I assume your requirements answer them.

Can you help me understand how requirements help me decide what
belongs *necessarily* in the database, and what doesn't?


I don't really care that someone responded "Yes" to the first
question, or that 72% of respondents answered "3" to the fourth
question. I *do* care if someone says that they did use tech support
in the past month, or if 72% said that their experience with tech
support was "average". Why doesn't the question belong in the
database, especially when the point of this design is to handle
questionnaires that can be completely different?

Then don't name your columns question_1 and question_4. Name them [used
tech support] and [tech support rating]

This is a matter of convenience, but not theoretical necessity,
correct?

Again, thanks for your well-thought-out, well-composed, informative
responses :)

.

Relevant Pages

  • Re: storing survey answers of different data types
    ... thanks for your informative responses. ... paper, in another digital format, or even in a relational database. ... Given that databases did not exist for 5 million years of human evolution and we all managed to get here, I would not argue for the necessity of putting anything in a database. ... I *do* care if someone says that they did use tech support ...
    (comp.databases.theory)
  • Re: storing survey answers of different data types
    ... "convenient" means in the dbms. ... requirement says to you " This calls for a database?" ... necessity of putting anything in a database. ... belongs *necessarily* in the database, ...
    (comp.databases.theory)
  • Re: Help Request
    ... you have not read all the responses to my ... database, because the expert offering the code doesn't have your database in ... The "Getting Started" newsgroup is intended for beginners. ... programming, event-oriented programming with objects, ensuring that the ...
    (microsoft.public.access.forms)
  • RE: Rank results
    ... There is no 'easy' way with a database only the 'right' way. ... What I would do is have respondent in the main form and responses in the ... I need to be able to rank these multiple ... intelligence scores to identify strengths and weaknesses in students. ...
    (microsoft.public.access.queries)
  • Re: Updating only fields which users have changed
    ... >> Thanks everyone for the responses. ... >> building a UPDATE statement of only the fields that have actually ... >> changed probably won't save much on the database end. ... > Yes there will be savings, but I regard it to be a case of premature ...
    (comp.lang.php)