Database design stage 1

[rs51]

i'm not sure where to post this.
i'm still in designing database stage but i'm thinking how i'll write the queries and what problems i'll find with php too.
Here's my situation:
i was asked to develop an intranet where users will have to answer about 80 questions each.
As i think that's too much long, i'm thinking in making forms with around 15-20 questions each time.
That implies that for each user i've to have an INSERT and for every other missing form have UPDATE queries as well.
Am i thinking correctly or is there a better way to organize this?
thanks in advance

 

[newphpbie]

Do it which ever way you feel most comfortable.

There is nothing to say PHP couldn't handle 80 field updates in one go. But I think you are going about it the right way by splitting it up into sections.

No-one really wants to scroll down for 80 questions, by seperating the questions into sections, it not only makes it easier for you to create and manage the code, but it makes it nicer for the users too.

I don't know what you mean by this..

implies that for each user i've to have an INSERT and for every other missing form have UPDATE

What do you mean by Missing form?

But I think your heading in the right direction...

Good luck.

 

[ArkM]

In any case the stage before DB design must be called "Functional Specifications". Imagine that you are an unhappy (wo)man obliged to answer to 80 questions (do you find it funny?). Identify yourself with users and their goals, for example:
Level 1 goals:
1. Start answer these dumned questions.
2. Add/Modify my answers.
3. Put may name to commitment.
Level 2 goals:
1. Open/Create Questionnare
2. Select Page (may be all questions together?)
4. Modify Page (client side, don't worry)
5. Send Page
6. Close Questionare.
7. Inspect Questionnare (is it ready?) - optional

Now interface design - it's a matter of taste. May be suggest to include all previous (earlier presented) answers (extracted from DB) in paged form field? An user can correct all his/her answers (it is more convenient: undo analogue) and you can simplify your server logic.

Here DB design is. Your database design must aquire functional specifications and interface requirements.

Problem area includes Person (interviewee, but only if it's not an anonymous interrogation, otherwise UID), Questionnare (1:1, <answer,question> pairs) - that's all. But you need some DB (process) artifacts: time stamps, page numbers, commitment flag etc. It seems Forms per se are not DB entities.

For example, if your Questionnare table has fields:
<QuestionNumber,Answer> (plus service fields, of course), you may insert all tuples with empty answers at new Questionnare creation time, then always UPDATE corresponding tuples after next form processing.

Conclusion: it seems if you put a (design) question in the proper context you may get a right answer.

 

[rs51]

i mean that since the user can post in several diferent times, it is allowed to post one day say 10 questions, next day more 20 and so on.
so, each user will have an ID, so the first form inserts with that id, but for next forms i've to UPDATE that very same record in the fields he hadnt fullfilled yet...

 

[rs51]

while i was typping people answered too, so:
ArkM :
i'm an absolute amateur and because i made my school databased site, now they asked me to write some intranet application to substitute some forms they had to answer by hand.

yes, i'm really trying to think ahead, that's why i asked it here, because that may affect my database design!
second - you guessed: its gonna be ladies... and middle aged ones some too, hehe.

Maybe i've to set some NULL fields because of your sugestion about empty or zero or &quot;&quot; values and then later update.
so far the database has about 25 tables, so you see, there's related data to insert too...

 

[rs51]

so sorry:
thanks to everyone who helped me!