[MySQL] Twijfels over database opzet

[MuddyMagical]

Ik ben bezig met het opzetten van een systeem voor het afnemen van enquete's. Het is de bedoeling dat men zelf enquete's en vragen kan toevoegen.
Nu zit ik al een tijdje te denken over hoe ik de verschillende dingen kan opslaan in mijn MySQL database maar ik loop op 1 aspect vast:

Bij het invoeren van een vraag moet ook aangegeven worden wat de mogelijke antwoorden zijn.
Er zijn over het algemeen de volgende mogelijkheden:

Ja - Nee
Wel - Misschien Wel - Onbekend - Misschien Niet - Niet (kies 1 v/d 5)
Een reeks van mogelijke antwoorden waaruit men meerdere kan kiezen.
Een reeks van mogelijke antwoorden waaruit men 1 optie kan kiezen.
Een open antwoord.

Nu is mijn vraag hoe ik dit het beste in 1 of misschien meerdere tabellen kan opslaan.
Zelf dacht ik aan het volgende:

tbl_answer
* idanswer
idtype_answer
answer1
answer2

.
.
.
answer24
answer25

tbl_type_answer
*idtype_answer
description
num_options
option1
option2
.
.
.
option24
option25

2 tabellen, tbl_answer en tbl_type_answer.
In tbl_answer komt het daadwerkelijke antwoord en in de tabel een verwijzing naar tbl_type_answer om te kijken welk type antwoord het is.

Maar ik ben niet helemaal tevreden met de constructie. Iemand een beter idee?

(Mocht het niet duidelijk zijn, dan hoor ik het graag.)

[m33p]

Kun je niet alles in 1 row gooien? Dus de vraag en de mogelijke antwoorden? Scheelt je wel een boel query's.

[Varienaja]

Quick & Dirty:

Een tabel met alle gegeven antwoorden in de vorm: ID, VraagID, A,B,C,D,E,F, VraagTypeID

In de veldjes A...F plaats je bitjes, en met behulp van de foreign key VraagTypeID kom je erachter of het een ja/nee vraag was, een meerkeuze-vraag, of een multiple-select-vraag.

Je kunt het ook mooi gaan ontwerpen, maar dan zou ik niet met een datamodel beginnen, maar met een objecten-diagram.

edit:
Ik heb heel je verhaal niet eens zo uitgebreid gelezen. Excuus daarvoor. Ik zie nu dat mijn quick*dirty verzinsel gelijk is aan het jouwe. Dat is misschien een geruststelling voor je, maar ik moet wl zeggen dat ik zelf eerst een objecten-model zou gaan maken.

[ Voor 26% gewijzigd door Varienaja op 21-09-2005 11:19 ]

[Verwijderd]

Ik zou het bijhouden m.b.v. een veld die de index aangeeft van het antwoord (answer_type_index) en een veld met answer_type_id. In een table answer staat dan de volgende kolommen:

sleutel: answer_id;
type: answer_type_id;
index: answer_type_index;
antwoord: answer_description

Zoiets had je ook al volgens mij als ik het goed begrijp.

[MuddyMagical]

Wat mij vooral tegenstaat in de oplossing waarmee ik zelf ook al gekomen was is de beperking van het aantal antwoorden. In principe moet het zo zijn dat men een oneindige hoeveelheid antwoordmogelijkheden moet kunnen geven bij een vraag. En niet de 25 die ik in mijn startpost aangeef.

[Verwijderd]

Een antwoord is en blijft een antwoord. Oftewel een tabel met maar 1 waarde, het antwoord. Een vraag bevat een setje mogelijk antwoorden. Dus een tabelletje antwoorden set en een tabelletje vraag. De rest vogel je denk ik zelf wel uit

[Verwijderd]

MuddyMagical schreef op woensdag 21 september 2005 @ 11:40:
Wat mij vooral tegenstaat in de oplossing waarmee ik zelf ook al gekomen was is de beperking van het aantal antwoorden. In principe moet het zo zijn dat men een oneindige hoeveelheid antwoordmogelijkheden moet kunnen geven bij een vraag. En niet de 25 die ik in mijn startpost aangeef.

Met mijn oplossing is dat wel mogelijk... Gewoon een nieuwe row toevoegen en klaar .

[Verwijderd]

Op zich lijkt jouw oplossing (ts) me geen ramp eigenlijk. Software moet scalable zijn, maar welke enqueteur gaat nou 30 antwoorden op zijn vraag verzinnen. Maar goed, met de oplossing hieronder kan je volgens mij onbeperkt antwoorden toevoegen


tbl_poll_answers
poll_id (primary key)
answer

tbl_poll_main_info
poll_id (primary key)
poll_description
answer_type

[ Voor 4% gewijzigd door Verwijderd op 21-09-2005 11:52 ]

[ripexx]

Dus gewoon normaliseren en met koppeltabellen gaan werken. Je levert dan niet in op flexibiliteit en je kan gewoon extra vragen, met mogelijke antwoorden toevoegen. Denk ook aan de mogelijkheid van openvragen en opties waarbij er meerdere keuzes mogelijk zijn.

[D4Skunk]

Wat jij eigenlijk vraagt, is de manier waarop je afgeleide classes moet opslaan in een relationele database, want elk type van vraag is eigenlijk een afgeleide class van de virtuele class vraag.
Ik weet niet of je bekend bent met het OO-concept, maar er bestaan verschillende manieren om gegevens te mappen van classes naar relationele databases. Google kan je hier wel verder bij helpen.

[Nielsz]

Verwijderd schreef op woensdag 21 september 2005 @ 11:51:
Op zich lijkt jouw oplossing (ts) me geen ramp eigenlijk. Software moet scalable zijn, maar welke enqueteur gaat nou 30 antwoorden op zijn vraag verzinnen. Maar goed, met de oplossing hieronder kan je volgens mij onbeperkt antwoorden toevoegen


tbl_poll_answers
poll_id (primary key)
answer

tbl_poll_main_info
poll_id (primary key)
poll_description
answer_type

Wat dacht je van: "Selecteer in welk jaar u lid bij ons geworden bent: "
en dan een selectbox van 1980 tot nu.

[Verwijderd]

Je kunt iemand ook gewoon zelf het jaar laten invullen, dan heb je maar 1 antwoord Maar goed, volgens mij is de opzet die ik postte wel ok toch? Je kunt er onbeperkt antwoorden mee toevoegen.

[Tinoo]

Tsja, oplossing is inderdaad niet verkeerd maar misschien kun je er nog een tabel aan toevoegen met de mogelijke antwoorden op een gesloten vraag anders het het veld 'anwer-type' ook weinig zin.

[BCC]

Spuit 11: Laat maar

[ Voor 135% gewijzigd door BCC op 21-09-2005 12:25 ]

[curry684]

Verwijderd schreef op woensdag 21 september 2005 @ 11:51:
Op zich lijkt jouw oplossing (ts) me geen ramp eigenlijk.

Genummerde velden in een tabel lijkt je geen ramp?

code:

Question
  int QuestionId primary key identity(1, 1)
  varchar(255) QuestionName
  int QuestionTypeId foreign key references QuestionType

QuestionType
  int QuestionTypeId primary key identity(1, 1)
  varchar(255) QuestionTypeValidationExpression nullable
  enum QuestionTypeStyle (single, multiple, freeform)

QuestionAnswer
  int QuestionAnswerId primary key identity(1, 1)
  varchar(255) QuestionAnswerValue

Survey
  int SurveyId primary key identity(1, 1)
  varchar(255) SurveyName

SurveyResponse
  int SurveyResponseId primary key identity(1, 1)
  int QuestionId foreign key references Question
  int SurveyId foreign key references Survey
  int User foreign key references User
  varchar(255) ResponseValue

Veel plezier ermee

[ Voor 4% gewijzigd door curry684 op 21-09-2005 12:27 ]

[Verwijderd]

curry684 schreef op woensdag 21 september 2005 @ 12:25:
[...]

Genummerde velden in een tabel lijkt je geen ramp?

Veel plezier ermee

Mjah, ik zei niet dat het ideaal was Voor een klein poll systeem zou het kunnen, maar het is idd verre van flexibel en gebruiksvriendelijk.

[Nielsz]

Vergeet je de "anders, nl: " niet?

[curry684]

Nielsz schreef op woensdag 21 september 2005 @ 12:50:
Vergeet je de "anders, nl: " niet?

Wie?

[Verwijderd]

Nielsz schreef op woensdag 21 september 2005 @ 12:50:
Vergeet je de "anders, nl: " niet?

Daar zit wat in, je moet een oplossing hebben voor niet-vaststaande antwoorden. Je zou er een veld bij kunnen doen in de tbl_poll_answer tabel (bijv. open_answer). Maar ik denk dat er nog wel meer van zulke vereisten bij komen als je alle specs van dit systeem eens goed op een rij zet.

[ Voor 32% gewijzigd door Verwijderd op 21-09-2005 13:05 ]

[curry684]

Die van mij is dus wel sluitend voor single-select, multiple-gok en open vragen, inclusief "Anders, nl" vragen

[MuddyMagical]

Nielsz schreef op woensdag 21 september 2005 @ 12:50:
Vergeet je de "anders, nl: " niet?

Nee, ook die vergeet ik niet.

Verwijderd schreef op woensdag 21 september 2005 @ 13:05:
[...]

Daar zit wat in, je moet een oplossing hebben voor niet-vaststaande antwoorden. Je zou er een veld bij kunnen doen in de tbl_poll_answer tabel (bijv. open_answer). Maar ik denk dat er nog wel meer van zulke vereisten bij komen als je alle specs van dit systeem eens goed op een rij zet.

You don't wanna know..

Ook verschillende talen zijn mogelijk en verschillende uitvoermogelijkheden. Het is een systeem dat door heel Europa gebruikt gaat worden.

[Morax]

MuddyMagical schreef op woensdag 21 september 2005 @ 13:13:
[...]

Nee, ook die vergeet ik niet.


[...]


You don't wanna know..

Ook verschillende talen zijn mogelijk en verschillende uitvoermogelijkheden. Het is een systeem dat door heel Europa gebruikt gaat worden.

Uit nieuwsgierigheid, waarmee maak je de applicatie? Word het een echte applicatie (Java, C) of maak je het in de vorm van een website (PHP)?

[Nielsz]

En nog meer nieuwsgierigheid: is dit alleen voor jouw bedrijf of ga je het verkopen?

[MuddyMagical]

Morax schreef op woensdag 21 september 2005 @ 14:21:
[...]


Uit nieuwsgierigheid, waarmee maak je de applicatie? Word het een echte applicatie (Java, C) of maak je het in de vorm van een website (PHP)?

Het wordt een website (soort CMS). In de vorm van een universeel systeem dat eventueel in elke website is te zetten om enquete's af te nemen.

Nielsz schreef op woensdag 21 september 2005 @ 16:29:
En nog meer nieuwsgierigheid: is dit alleen voor jouw bedrijf of ga je het verkopen?

Het systeem is een opdracht van een vriend van me die ongeveer gek werd van de antwoorden die via mail naar hem toe kwamen. Of het verkoopbaar is moet nog blijken.

[Janoz]

Gewoon uitnormaliseren. Dan kom je uit op wat Curry ook al poste. Ikzelf heb ook een enqueteer applicatie ontwikkeld. Het enquete onderdeel in de database kwam redelijk overeen met wat curry ook post. Alleen heb ik het varchar responce veld in een apparte tabel met een fk naar SurveyResponse en kopelde ik die records niet aan een question, maar aan een QuestionAnswer.

[curry684]

offtopic:
ik heb met een vrijwel identieke constructie als wat ik postte recent een Activity Based Costing surveying tool uitgerold

[MuddyMagical]

Maakt iedereen hiero enqueteer applicaties?!

[Nielsz]

Blijkbaar
Ik wel iig

[ Voor 4% gewijzigd door Nielsz op 23-09-2005 12:01 ]

[Janoz]

offtopic:
[op bied mode]
De gui en gegenereerde html van mijn applicatie (www.enquetegenerator.nl, ondertussen werk ik daar niet meer) was zo prettig dat hij tegenwoordig ook als formulier generator voor verschillende e-loketten in nederland wordt ingezet.

[curry684]

MuddyMagical schreef op donderdag 22 september 2005 @ 13:15:
Maakt iedereen hiero enqueteer applicaties?!

Alleen als de klant betaalt

Zit op dit exacte moment overigens in de User Acceptance Test conference call voor die tool van mij

[ Voor 22% gewijzigd door curry684 op 23-09-2005 10:36 ]