Archief - enquete tabellen

Ik zou een websiteje moeten maken waarop enquetes gemaakt moeten worden.
Nu zit ik wat te brainstormen over de tabelstructuur, maar ik kom er niet goed uit.

Eerst zag ik het heel simpel, dus een tabel "form" met een veld "welkomstekst", etc.
Dan een tabel "vragen" met vraagID, vraag, keuzes en vraagTypeID

De tabel vraagType bevat dan uiteraard de vraagtypes zoals radio, checkbox, invulveld, etc..

En dan tot slot de tabel antwoord waarin dan gewoon een antwoordID zit samen met de vraagID en het antwoord.

Nu was ik echer aan het denken of dat wel proper is?
En of het niet beter is om aan de tabel vraag nog een tabel vraagantwoorden te koppelen, dus:

vraag
vraagID
vraag

vraagAntwoorden
vraagAntwoordID
vraagID
antwoord

en daarin dan volgende gegevens bijvoorbeeld:
vraag
1
je favoriet fruit

vraagAntwoorden
1
1
banaan

vraagAntwoorden
2
1
appel

vraagAntwoorden
3
1
peer

Met andere woorden wil ik dus de keuzes van een vraag niet gescheiden door een komma opslaan, maar opsplitsen naar een aparte tabel omdat mij dat properder lijkt, of ben ik het hier te ver aan het zoeken?

Het is inderdaad netter als je vraag en antwoorden in een aparte tabel onderbrengt. Dit is ook meestal de gang van zaken bij bv. polls op een forum.

Sick-Boy zei:

Het is inderdaad netter als je vraag en antwoorden in een aparte tabel onderbrengt. Dit is ook meestal de gang van zaken bij bv. polls op een forum.

Klik om te vergroten...

yep da weet ik, maar een poll is gewoon een tabel met vragen en een tabel met antwoorden per persoon op een van de vragen.

Wat ik bedoel is of ik de tabel "vragen" nog in twee tabellen moet opsplitsen, dus de hoofdvraag "wat is je lievelingskleur" in de tabel vraag, en dan de kleuren als aparte records in een tabel "vraagantwoorden".
Bijvoorbeeld "blauw", "groen", "rood"
De antwoorden van de personen die de enquete dan invullen worden in een tabel "antwoorden" dan gekoppeld aan de "vraagantwoorden" entries.

in plaats van gewoon

tabel: vraag
vraagID:1
titel: wat is je lievelingskleur
waarden:blauw,groen,rood

tabel:antwoord
antwoordID:1
vraagID:1
antwoord:true,false,false

maak ik er dan van

tabel: vraag
vraagID:1
titel: wat is je lievelingskleur

tabel:vraagantwoorden
vraagAntwoordID:1
vraagID:1
antwoord:rood

tabel:vraagantwoorden
vraagAntwoordID:2
vraagID:1
antwoord:blauw

tabel:vraagantwoorden
vraagAntwoordID:3
vraagID:1
antwoord:groen

tabel:antwoord
antwoordID:1
vraagAntwoordID:1
antwoord:true

tabel:antwoord
antwoordID:2
vraagAntwoordID:2
antwoord:false

tabel:antwoord
antwoordID:3
vraagAntwoordID:3
antwoord:false

Wat jij er van maakt is goed, al zou ik geen entry aanmaken voor antwoorden die niet geselecteerd zijn. Ik zou ook de benamingen wat veranderen, want nu is het wat verwarrend. Die kolom antwoordID is ook overbodig (al moet je wel een andere foreign key gebruiken zoals bv. UserID, anders kan die kolom antwoord ook gewoon als kolom bij de tabel vraagantwoorden).

De kolom antwoordID is de primary key he
ipv vraagantwoorden zou "vraagkeuzes" mss een betere naam zijn idd.

Een primary key is een combinatie van een of meerdere kolommen dat je data definieert. Een identity column kan een primary key zijn, maar er bestaan ook zgn. composite primary keys. Omdat bovenstaande tabellen een 1-op-1 relatie hebben voor antwoord en vraagAntwoord raad ik je aan om ze samen te voegen. Als je voor elke gebruiker die de enquête invult een entry in de tabel vraagAntwoord aanmaakt, dan kan je een kolom UserID toevoegen. In dit geval is de combinatie UserID-vraagAntwoordID uniek en kan dan als primary key dienen. Tenzij je gebruikers toelaat om meerdere keren dezelfde enquête in te vullen.

de tabel vraagantwoord is enkel om bij te houden welke antwoorden er bij een vraag horen he en antwoordID is niet meer als een auto increment primary key.

ik heb vraagantwoorden door een duidelijkere naam vervangen.

vraag
vraagID
titel

vraagkeuzeopties
vraagkeuzeOptieID
omschrijving
waarde
vraagID

antwoord
antwoordID
vraagID
userID
antwoord

Je krijgt dan bijvoorbeeld in de vraag tabel: "wat je is lievelingskleur"
In de tabel vraagkeuzeopties krijg je dan bijvoorbeeld 3 entries "blauw","groen","rood" die bij de enquete worden opgehaald.
Als een user er dan een van kiest wordt een entry toegevoegd aan "antwoord" met de waarde.

Deze laatste twee tabellen samenvoegen lijkt mij niet echt de bedoeling?

Ga je daar 1 enquete (dus 1 vaste vragenlijst) mee afnemen, of is het de bedoeling dat er meerdere zijn? Heb je enkel meerkeuzevragen met 1 mogelijk antwoord (radio), geen met meerdere antwoorden (checkbox) of open (vrij invulbare) vragen (text/textarea)? Sowieso is wat hier net boven staat al een goede basis om mee te starten.

dJeez zei:

Ga je daar 1 enquete (dus 1 vaste vragenlijst) mee afnemen, of is het de bedoeling dat er meerdere zijn? Heb je enkel meerkeuzevragen met 1 mogelijk antwoord (radio), geen met meerdere antwoorden (checkbox) of open (vrij invulbare) vragen (text/textarea)? Sowieso is wat hier net boven staat al een goede basis om mee te starten.

Klik om te vergroten...

De vragen kunnen idd ofwel invulveld zijn, radio (een keuze mogelijk) of checkboxes (meer keuzes mogelijk).
Het is ook de bedoeling dat er zelf enquetes gemaakt worden op termijn die dan weer ingevuld worden.

Vandaar dat ik die tussentabel (vraagkeuzeopties) wil voorzien om die te linken aan een vraag uit de vraagtabel met verschillende records per mogelijkheid.

Dus in de tabel vraag "wat is je lievelingskleur"
en dan in de tabel vraagkeuzeopties drie records "rood", "groen", "blauw" met respectievelijk de waarden 1,2,3

ALs iemand dan groen kiest komt in de antwoordtabel de waarde 2 te staan en de userID en de vraagID bijvoorbeeld.

Ik snap dat je dat bij iedere tabel doet, een identity column toevoegen, maar je hebt een primary key, namelijk (vraagID,userID). Omdat die combinatie uniek is, is het nutteloos om een extra kolom te gebruiken als primary key. Tenzij die gebruikt wordt als foreign key in een andere tabel. Ook als je meerdere antwoorden toelaat, dan maak je van de primary key (vraagID,userID,antwoord).

Ik zeg het maar omdat als je begaan bent met de properheid van de structuur van je tabellen, dan ben je misschien ook begaan met de efficiëntie.

Om dezelfde reden is die vraagkeuzeOptieID niet nodig, omdat je al een unieke combinatie hebt met (vraagID,waarde). Hier zou je wel kunnen het ID van de keuze opslaan in de tabel antwoord ipv een string antwoord.

Als je effectief meerdere verschillende enquetes wil gaan bijhouden dan ontbreekt uiteraard nog een enquetetabel (en de nodige links daar naartoe in je huidige tabellen).

Sick-Boy zei:

Om dezelfde reden is die vraagkeuzeOptieID niet nodig, omdat je al een unieke combinatie hebt met (vraagID,waarde). Hier zou je wel kunnen het ID van de keuze opslaan in de tabel antwoord ipv een string antwoord.

Klik om te vergroten...

Dat hangt ervan af wat hij onder "waarde" verstaat natuurlijk. Als dat een veld is dat business waarde bevat (die zou kunnen wijzigen over een periode), dan kan je beter een unieke key toevoegen.

En hij heeft zowel de ID van de keuze als een tekstveld nodig bij antwoorden. In het eerste hou je de IDs van de aangevinkte optie(s) bij, in het tweede de tekst die in de vrije invulvelden werd ingevuld. Het type van vraag (een veld dat nu ontbreekt) zal dan bepalen welk antwoord je gaat hanteren.

dJeez zei:

Als je effectief meerdere verschillende enquetes wil gaan bijhouden dan ontbreekt uiteraard nog een enquetetabel (en de nodige links daar naartoe in je huidige tabellen).


Dat hangt ervan af wat hij onder "waarde" verstaat natuurlijk. Als dat een veld is dat business waarde bevat (die zou kunnen wijzigen over een periode), dan kan je beter een unieke key toevoegen.

En hij heeft zowel de ID van de keuze als een tekstveld nodig bij antwoorden. In het eerste hou je de IDs van de aangevinkte optie(s) bij, in het tweede de tekst die in de vrije invulvelden werd ingevuld. Het type van vraag (een veld dat nu ontbreekt) zal dan bepalen welk antwoord je gaat hanteren.

Klik om te vergroten...

De enquetetabel ontbreekt nog ja, mijn voorstelling was ook heel specifiek en beknopt, komt natuurlijk ook nog een usertabel en een tabel enquetetype.
Ik wilde bij antwoord dan de waarde of de ingevulde tekst zetten, maar het is idd mss beter om twee velden te voorzien zoals je zegt.