Enquete DataBase ontwerp

[Verwijderd]

Ik ben bezig om een enquete online te zetten, maar zit met wat vragen omtrent het database ontwerp.

De enquete bestaat uit ongeveer 20 vragen. Hoe je op sommige vragen antwoordt bepaalt naar welke volgende vraag je gaat. Bij sommige vragen zijn meerdere antwoorden mogelijk.

Het makkelijkst is natuurlijk om alle antwoorden in 1 tabel te stoppen, maar volgens mij wordt dit alles wat onoverzichtelijk als je een tabel krijgt met meer dan 30 kolomen.

Bovendien zit je dan met het feit dat sommige bepaalde vragen niet hoeven te beantwoorden, maar de genenen die die vraag wel beantwoorden verplicht een antwoord moeten geven. (dit is opzich nog wel op te lossen in de applicatie)

Maar voor elke vraag 1 tabel maken is ook niet efficient. Bovendien moet je dan elke tabel met elkaar linken.

Ik wil gebruik gaan maken van MySQL en PHP

Graag zou ik wat iedeen van jullie horen over hoe ik het best me Database ontwerp kan maken.

[drm]

Het makkelijkst is natuurlijk om alle antwoorden in 1 tabel te stoppen, maar volgens mij wordt dit alles wat onoverzichtelijk als je een tabel krijgt met meer dan 30 kolomen.

Waarom zou je dat een tabel van dertig kolommen opleveren

Volgens mij kun je het beste 1 tabel met vragen maken, 1 met antwoorden, en die koppelen door te zeggen: 'als bij die vraag (vraag_id) dat antwoord (antwoord_id) is gegeven is dit (next_vraag_id) de volgende vraag'.

Snap je wat ik bedoel?

[gorgi_19]

Voor de structuur:

1 enquete (tabel) heeft 1 of meerdere vragen (tabel)
1 vraag heeft een of meerdere antwoordmogelijkheden(tabel)

Vervolgens hebben we een aantal (al dan niet) anonieme bezoekers (tabel). Deze geven antwoorden(tabel); opgeslagen wordt de bezoekerID, vraagID, antwoordID.

[Verwijderd]

drm schreef op 21 February 2003 @ 12:54:
[...]
Waarom zou je dat een tabel van dertig kolommen opleveren

Volgens mij kun je het beste 1 tabel met vragen maken, 1 met antwoorden, en die koppelen door te zeggen: 'als bij die vraag (vraag_id) dat antwoord (antwoord_id) is gegeven is dit (next_vraag_id) de volgende vraag'.

Snap je wat ik bedoel?

Nee niet helemaal, want waarom zou ik de vragen ook in de database op willen slaan? Die komen gewoon in de code te staan dacht ik aan. Als dit een grote denk fout is hoor ik het graag.

Ik zelf dacht aan het volgende. (als je naar het relationele representatie model zou kijken)

enquete ( ID, vraag1, vraag2, vraag3, vraag4, ...........ect)

Maar dit voor 20 vragen, en voor sommige vragen zijn meerdere antwoorden mogelijk, wordt het dan niet onoverzichtelijk.

Nog een vraag is het mogelijk om in MySQL Constrains te maken?

[gorgi_19]

* gorgi_19 schrikt...

Tabel enquete
EnqueteID
Omschrijving

Tabel vragen
VraagID
EnqueteID
Vraag

Tabel antwoordmogelijkheden
AntwoordID
VraagID
Antwoord

...

[Bobco]

En nog even een aanvulling op het modelletje van gorgi_19: neem bij elk antwoord ook nog op wat het ID is van de volgende vraag en je kunt meteen de situatie aan dat als er A wordt geantwoord op vraag 1 vraag 2 gesteld moet worden en dat als antwoord B op vraag 1 gegeven wordt vraag 5 moet worden gesteld.

[gorgi_19]

Bobco schreef op 21 February 2003 @ 13:22:
En nog even een aanvulling op het modelletje van gorgi_19: neem bij elk antwoord ook nog op wat het ID is van de volgende vraag en je kunt meteen de situatie aan dat als er A wordt geantwoord op vraag 1 vraag 2 gesteld moet worden en dat als antwoord B op vraag 1 gegeven wordt vraag 5 moet worden gesteld.

Ik zou er dan een volgorde aan koppelen. Eventueel kan je nog een koppeltabel maken, als de antwoorden veelgebruikt worden (bijvoorbeeld: ja, nee, soms, misschien)

[Glimi]

Verwijderd schreef op 21 februari 2003 @ 13:06:
Nee niet helemaal, want waarom zou ik de vragen ook in de database op willen slaan? Die komen gewoon in de code te staan dacht ik aan. Als dit een grote denk fout is hoor ik het graag.

Waarom zou je de vragen willen hard coden? Stel er komt overmorgen iemand naar je toe en vraagt of ie ook een enquete mag hosten bij je. Dan moet jij alles pagína's copieren, de vragen veranderen en een database aanmaken Terwijl je ook gewoon wat vraagjes kan veranderen in de database.

Houd je code zo generiek mogelijk, dan is het makkelijker vaker in te zetten

Nog een vraag is het mogelijk om in MySQL Constrains te maken?

Hangt af van je versie van MySQL. Probeer maar in de handleiding op te zoeken of InnoDB tableshandlers in je versie ondersteund zijn. Zoja, dan zijn FK's en transactions mogelijk

[Freee!!]

Gorgi_19, volgens mij ben je de tabel met gegeven antwoorden vergeten.

[gorgi_19]

Mr. Liu schreef op 21 February 2003 @ 13:28:
Gorgi_19, volgens mij ben je de tabel met gegeven antwoorden vergeten.

Nee hoor, was alleen maar een opzetje... Ik ga geen compleet antwoordmodel voorschotelen..

[ Voor 22% gewijzigd door gorgi_19 op 21-02-2003 13:29 ]

[Freee!!]

gorgi_19 schreef op 21 February 2003 @ 13:29:
[...]
Nee hoor, was alleen maar een opzetje...

Het was al redelijk compleet

Ik ga geen compleet antwoordmodel voorschotelen..

Verstandig

edit:

"..." aan het eind over het hoofd gezien

[ Voor 13% gewijzigd door Freee!! op 21-02-2003 13:32 . Reden: "..." ]

[drm]

Dat zei ik idd ook al

drm:
Volgens mij kun je het beste 1 tabel met vragen maken, 1 met antwoorden, en die koppelen door te zeggen: 'als bij die vraag (vraag_id) dat antwoord (antwoord_id) is gegeven is dit (next_vraag_id) de volgende vraag'.

Aan de hand van die tabel zie je namelijk meteen welke antwoorden bij welke vraag horen, en voorkom je redundantie door bij meerdere vragen dezelfde antwoorden op te moeten slaan in een 1:N relatie. Eventueel kun je nog een boolean veld toevoegen waarin je zegt of het de laatste vraag is in een reeks, maar dat zou je ook op kunnen lossen (beetje bah, maar goed) door next_vraag_id NULL te setten.

Anyhoet, Viper144, het lijkt mij het handigst als je even een database-ontwerp tutorial opzoekt, want de voorstellen die je nu doet, kunnen echt regelrecht de prullenbak in, als het gaat om database ontwerpen

Dit topic laat ik nog wel even open om even verder te filosoferen over wat het beste databaseontwerp zou kunnen zijn, want er zijn vast nog wel meer ideeen

[Verwijderd]

Ok tnx voor de aanwijzingen.

Ik ga nu wel ff proberen me ontwerp te maken. Zal kijken of het me lukt om gorgi_19 ontwerp verder uit te werken.

Als het topic open mag blijven graag, want dan kan ik straks ff posten wat ik er van gemaakt heb en dan jullie mening daar over horen.

[Verwijderd]

Na vooral wat gorgi_19 als opzet gaf heb ik het volgende gemaakt.

Maar het probleem met dit model is, hoe pas ik hier in vragen, waar meerdere antwoorden op mogelijk zijn (want die zijn er) en hoe komen openvragen hier in (want die zijn er ook)

Hopelijk zijn er nog mensen die met tips kunnen komen, bijvoorbaat dank!

enquete (enqueteID, omschrijving)
pk (enqueteID)

vragen (vraagID, enqueteID, vraag)
pk (vraagID)
fk (enqueteID) references enquete

ant_mogelijkheden (antwoordID, vraagID, antwoord)
pk (antwoordID)
fk (vraagID) references vragen

bezoeker (bezoekerID, enqueteID)
pk (bezoekerID)
fk (enqueteID) references enquete

antwoorden (bezoekerID, vraagID, antwoordID)
pk (???) (een combinatie van alle3 kan, maar is het slimmer om gewoon een nieuwe te maken?)
fk (bezoekerID) references bezoeker
fk (vraagID) references vragen
fk (antwoordID) references ant_mogelijkheden

[Verwijderd]

Meerdere vragen op een antwoord levert natuurlijk weer een nieuwe tabel op waarin je vraagid en antwoord id koppeld. Daarbij nog een ID dat weer in je antwoorden tabel gebruikt wordt.
Of je zou de antwoordID's puntkomma gescheiden in je antwoordID veld in je antwoorden tabel kunnen opnemen. Je zult dan in je applicatie code moeten maken die hiermee om kan gaan.

[gorgi_19]

Verwijderd schreef op 22 February 2003 @ 11:21:
Meerdere vragen op een antwoord levert natuurlijk weer een nieuwe tabel op waarin je vraagid en antwoord id koppeld. Daarbij nog een ID dat weer in je antwoorden tabel gebruikt wordt.

Dat kan, dat je hier een koppeltabel van maakt..

Of je zou de antwoordID's puntkomma gescheiden in je antwoordID veld in je antwoorden tabel kunnen opnemen. Je zult dan in je applicatie code moeten maken die hiermee om kan gaan.

Erhm... Zou dit niet doen. Laat een database dit lekker uitzoeken.
* gorgi_19 vindt dit een beetje heel erg tegen de regels van databaseontwerp ingaan, zie ook de normaalvormen.

[Verwijderd]

Ben nog niet helemaal tevreden met me ontwerp, dus ik hoop dat er nog mensen zijn die me er mee kunnen helpen.

Zal eerst nog ff wat meer uitleggen over de enquete.

Er kan op de volgende manieren worden geantwoord.

-Een keuze vraag, waar maar 1 antwoord op kan worden aangevinkt.
-Een keuze vraag, waar meerdere antwoorden op kunnen worden aangevinkt.
-Open vragen.
-Keuze vraag plus open vraag, denk hier bij aan een lijst waar je uit kan kiezen en als laatste optie word gegeven ander.............. (dus je vinkt eerst anders aan en vult daarna wat in in een textfield.

Ook is er een vraag, waar je moet vertellen welke steden je allemaal hebt bezocht en of je daar een cijfer voor kan geven. er komen dus 3 textvelden. Land Stad en cijfer. En zo meerder onder elkaar.

En zo ben ik tot nu toe gekomen tot het volgende ontwerp:

enquetes (enqueteID, omschrijving)

bezoekers (bezoekerID, enqueteID)

antwoorden (antwoordenID, bezoekerID, vraagID)

keuzeantwoord (k_antwoordID, antwoord)

openantwoord (o_antwoordID, regel, veld, antwoord)

maar graag zou ik willen weten of dit nu een beetje klopt!

[Verwijderd]

code:

dbo_quiz
QuizID
QuizDescription
InitialQuestionID

dbo_questions
QuestionID
QuizID
Question
NextQuestionId

dbo_QA
QuestionAnswerID
QuestionID
AnswerLong
AnswerShort
ScoreAnswer

dbo_Answers
QuizID
QuestionID
AnswerID
UserID

dbo_users
UserID
normale spul

Dit ontwerp heb ik zelf gebruikt voor een klant van me; in het Quiz tabel kun je zeggen met welke vraag de quiz moet beginnen; vervolgens heeft het Vragen tabel een NextQuestionID. Ik ga er vanuit dat iedereen snapt wat daarmee wordt bedoelt; tot heden werkt het prima. Op deze manier kun je de vragen in de database hergebruiken voor andere quiz-en. Bij de versie ik gebruik kan de quiz-er maximaal drie keer proberen; hierbij wordt de score bijgehouden.

[Verwijderd]

De database die jij geeft is dat je de antwoorden van te voren definieerd, maar als je met openvragen zit, wordt dat dus lastig volgens mij.

[Freee!!]

Verwijderd schreef op 27 February 2003 @ 16:19:
De database die jij geeft is dat je de antwoorden van te voren definieerd, maar als je met openvragen zit, wordt dat dus lastig volgens mij.

Dat is alleen een kleine aanpassing in dbo_Answers en een indicatie bij de vraag (ook een kleine aanpassing) dat het een open vraag is (hoeven dus geen antwoorden gedefinieerd te worden). Het bepalen en verwerken van de score wordt dan wel wat lastiger (zeker als er ook MC vragen zijn).

[Verwijderd]

Mr. Liu schreef op 27 February 2003 @ 16:22:
[...]

Dat is alleen een kleine aanpassing in dbo_Answers en een indicatie bij de vraag (ook een kleine aanpassing) dat het een open vraag is (hoeven dus geen antwoorden gedefinieerd te worden). Het bepalen en verwerken van de score wordt dan wel wat lastiger (zeker als er ook MC vragen zijn).

ik ben bezig met een gewone enquete, dus ik hoef geen score bij te houden volgens mij!

Verder hoeven van de keuze vragen alleen maar integers of Ja of Nee te worden opgeslagen, dus tabbel als QuestionAnwsers of Antwoordmogelijkheden lijken mij dat niet echt nodig.

[ Voor 16% gewijzigd door Verwijderd op 27-02-2003 17:12 ]

[Verwijderd]

Ach, dat ontwerp was ook alleen maar voor de Westlife-web-site.
Maar wel goed idee, mogelijkheid tot open vragen
Automatisch Scores toekennen bij Open Vragen wordt natuurlijk lastig; maar ja das niet mij probleem, haha

[Verwijderd]

maar ok, dit alles lost mijn probleem niet op!

wat is nou de mening van mijn ontwerp!
en kan dit zo?

[Verwijderd]

Nou met alles wat hier staat kun je een prima datamodel maken voor je Enquete hoor

[Verwijderd]

Verwijderd schreef op 28 February 2003 @ 10:43:
Nou met alles wat hier staat kun je een prima datamodel maken voor je Enquete hoor

Dat had ik dus al, maar ik wou jullie mening er ff over horen!

code:

enquetes (enqueteID, omschrijving)

bezoekers (bezoekerID, enqueteID)

vragen (vraagID, vraag)

antwoorden (antwoordenID, bezoekerID, vraagID)

keuzeantwoord (k_antwoordID, antwoord)

openantwoord (o_antwoordID, regel, veld, antwoord)

Ik zelf dacht antwoord mogelijkheden niet op te slaan, omdat er alleen maar intgers hoeven worden opgeslagen (als antwoord) en verder openvragen.

[Freee!!]

Verwijderd schreef op 28 February 2003 @ 12:19:
[...]
Dat had ik dus al, maar ik wou jullie mening er ff over horen!
<knip in code>
Ik zelf dacht antwoord mogelijkheden niet op te slaan, omdat er alleen maar intgers hoeven worden opgeslagen (als antwoord) en verder openvragen.

Het ziet er allemaal redelijk uit, maar zoals ze aan de andere kant van het water zeggen: The proof of the pudding is in the eating.

Maak het eens en kijk of je er goed mee kunt werken. Je zult altijd met kleine aanpassingen aan het ontwerp blijven zitten als je aan zoiets begint.

Rest mij nog één ding:
* Freee!! wenst je succes

[Verwijderd]

Mr. Liu schreef op 28 February 2003 @ 12:26:
[...]

Het ziet er allemaal redelijk uit, maar zoals ze aan de andere kant van het water zeggen: The proof of the pudding is in the eating.

Maak het eens en kijk of je er goed mee kunt werken. Je zult altijd met kleine aanpassingen aan het ontwerp blijven zitten als je aan zoiets begint.

Rest mij nog één ding:
/me wenst je succes

Ok ben er al aan begonnen, maar wou ff weten of niet iemand nu over zijn nek zou gaan!

[Freee!!]

Verwijderd schreef op 28 February 2003 @ 12:33:
[...]
Ok ben er al aan begonnen, maar wou ff weten of niet iemand nu over zijn nek zou gaan!

Natuurlijk gaan er een paar over hun nek

Zet twee DBA's bij elkaar en je hebt minimaal drie meningen (ieder persoonlijk en van het bedrijf waar ze werken, dus meer als ze bij verschillende bedrijven werken).