Re: storing survey answers of different data types

On Apr 23, 10:32 am, Bob Badour <bbad..._at_pei.sympatico.ca> 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 :) Received on Thu Apr 23 2009 - 20:30:26 CEST