Udarbejdning af database design til spørgeskema site

Under mit eget studie skulle vores afgangsprojekt faktisk være et system til brugeroprettelse til at lave en dynamisk "opret bruger"-process som ville kunne ændres.
Så man ikke på forhånd vidste hvad der skulle oplyses for at kunne lave en bruger og ville kunne ændre sig undervejs.
Dit scenarie er lidt nemmere fordi at du ikke skal ændre i eksisterende brugere.

Hvis du tænker dig om så er der to dele i det - spørgsmål og svar.
Hvis det første er at lave muligheden for at lave spørgsmål så hjælper det.

Hvert spørgsmål har tilknyttet svarmuligheder.
Question:
ID
Aktivt?
Spørgsmålet (teksten)
Svartype (Textarea, Textfield, radiobutton, checkbox)
StartSvarTekst (start tekst der står i fx et tekstfelt?)

AnswerPossibilties:
ID
QuestionID
Tekst

Her ville jeg ikke mene du burde have behov for typen fordi det får du igennem Svartype i Questions, og du skal her blot have alle de tekster du skal have til hver svarmulighed.

Husk at ved flere svarmuligheder til hvert spørgsmål indsættes bare flere rækker med samme QuestionID.

Answers:
Når du skal registrere hvad svarene er, så kan du faktisk næjes med at registrere hvilke AnswerPossibilties's ID der er valgt, men hvis du vil gøre din tabel mere læselig for sig selv kan du tage mere med såsom QuestionID.

Samme gør sig gældende som ved ovenstående med flere rækker.

P.S. Har ikke læst dit link, hvis det har meget betydning for den løsning du ønsker.

P.P.S. Hvad er forskellen på textArea og textfield ud over det kan være på flere linier?

Jeg tror jeg ville gøre noget hen af dette:

Spørgeskema anvendes til at holde styr på de forskellige skemaer. Der kan evt. tilføjes flere felter som kan bruges, fx hvem der har oprettet den.
Spørgeskema:
ID (Primery key)
Navn
Dato (Timestamp)
Aktiv

Anvendes til at holde styr på de forskellige spørgsmål. Typen er den type svar det skal være, sæt den evt som ENUM. Så tjekker du så på om du skal kigge efter i dine svarmuligheder. Så hvis den er sat til til inputfield eller textarea så viser du blot dem. Hvis den derimod er sat til checkbox eller radio så kigger du efter i tabellen Svarmuligheder efter dem som har fremmednøglen som passer til spørgsmålets id.
Spørgsmål:
ID (Primery Key)
Spørgsmål
Billede
Type
Spørgeskema_id (fremmednøgle for Spørgeskema)

Her gemmes kun svarmuligheder for radio og checkbox
Svarmuligheder:
ID
Svar
Billede
Spørgmål_id (fremmednøgle for Spørgsmål)

Her gemmer du det svar fra brugeren der er anvendt, uanset hvilken type der er anvendt.
Svar:
ID
Svar
Date (Timestamp)
Spørgsmål_id (fremmednøgle for Spørgsmål)

Det ville være sådan jeg ville gøre det.
Måske man kan modificere det lidt så svar fra radio og checkbox ikke kommer til at ligge i databasen to gange. Men du får måske en enklere søgning ved at du har alle svar samlet i en tabel.

Personligt ville jeg nok lave noget i stil med:
Skema
ID (PK)
...
...
...

Spm
ID (PK)
...
...
FK_skema (FK)

Svar
ID (PK)
FK_svar_type (FK)
FK_svar_{TYPE} (FK)
FK_spm (FK)

svar_type
ID (PK)
Tekstbox
Checkbox
radio
...
...

svar_{TYPE} (type kan være checkbox, radio, så du får en tabel for enhver svar type)
ID

Nu kan du så tilføje de relevante felter til enhver svar type.

Ved at gøre det på denne måde undgår du NULL værdier. Samt at du undgår redundant data, da der kun vil en forekomst af enhver svar-mulighed.

Det skal dog siger at denne måde ikke er den nemmeste at få sine resultater fra da det kræver en del JOINs.

Gerne tænk over hvilke udvidelses/statistik muligheder du vil have senere.
Vil du vide hvilken IP der har svaret? Så skal du skrive dette ind ved svaret.
Vil du vide hvornår der er svaret? Så skal der tidsstempel på - og tænk på om du vil registrere hvornår de trykker (så det javascript) eller hvornår de sender svaret (backend på serveren).
Vil du vide hvilken rækkefølge de har svaret i?
Give mulighed for at de kan fuldende senere?

Alt sammen ting der går ud over basis designet som du kan lave senere, men er rigtigt dejlige at have nu så det er en del af dit design, plus du får statistik fra start (selvom du måske først bruger det senere).
Det med statistik er altid mest brugbar jo mere data du har, så hvis det er noget du vil have så skal du have det så tidligt som muligt for vil kun blive mere brugbart jo længere tid du har det på

Good luck med det.

Answers:
Når du skal registrere hvad svarene er, så kan du faktisk næjes med at registrere hvilke AnswerPossibilties's ID der er valgt, men hvis du vil gøre din tabel mere læselig for sig selv kan du tage mere med såsom QuestionID.

Samme gør sig gældende som ved ovenstående med flere rækker.

Du skriver til Answers at der her bare skal referres AnswerPossibilties id. Men hvordan havde du da tænkt dig at jeg skal gemme svar på textfield og textarea svar?

P.P.S. Hvad er forskellen på textArea og textfield ud over det kan være på flere linier?

Forskellen mellem textarea og textfield er som du siger længden. Jeg tilføjede det blot, da det udyber hvilke typer svar jeg ønsker.

Gerne tænk over hvilke udvidelses/statistik muligheder du vil have senere.
Vil du vide hvilken IP der har svaret? Så skal du skrive dette ind ved svaret.
Vil du vide hvornår der er svaret? Så skal der tidsstempel på - og tænk på om du vil registrere hvornår de trykker (så det javascript) eller hvornår de sender svaret (backend på serveren).
Vil du vide hvilken rækkefølge de har svaret i?
Give mulighed for at de kan fuldende senere?

Alt sammen ting der går ud over basis designet som du kan lave senere, men er rigtigt dejlige at have nu så det er en del af dit design, plus du får statistik fra start (selvom du måske først bruger det senere).
Det med statistik er altid mest brugbar jo mere data du har, så hvis det er noget du vil have så skal du have det så tidligt som muligt for vil kun blive mere brugbart jo længere tid du har det på

Good luck med det.

God pointe

Det her site burde virkelig kigge StackOverflow over skulderen hvad angår kommentarer

Svar
ID (PK)
FK_svar_type (FK)
FK_svar_{TYPE} (FK)
FK_spm (FK)

svar_type
ID (PK)
Tekstbox
Checkbox
radio
...
...

svar_{TYPE} (type kan være checkbox, radio, så du får en tabel for enhver svar type)
ID

Nu kan du så tilføje de relevante felter til enhver svar type.

Jeg forstår ikke helt fremgangsmåden her? Hvad mener du med 'FK_svar_{TYPE} (FK)' hvordan laver man en FK der har en variabel? Det tror jeg da ikke er muligt.

Men jeg synes det er fedt at der ikke kommer NULL værdier og man samtidig kun gemmer svar en gang. Ville gerne høre mere.

Det skal dog siger at denne måde ikke er den nemmeste at få sine resultater fra da det kræver en del JOINs.

Jeg bruger heldigvis Eloquent ORM så det er ikke noget problem

Det bliver en kombineret nøgle.

svar_type fortæller dig hvilken tabel nu skal kigge i

og 'FK_svar_{TYPE}' fortæller dig ID på svaret i den relevante tabel.

Dette skal du håndterer programmatisk.