[SQL] Database ontwerp

[Verwijderd]

Mijn opdracht:
Maak een enquete wizzard voor op internet. N00bs moeten dus een enquete aan kunnen maken en andere n00bs moeten hem dus weer kunnen invullen. Maar er moeten ook meedere mensen tegelijk een enquete kunnen maken en op dat moment gebruiken.

Mijn probleem:
De enquete heeft geen vaste vorm. Dat wil zeggen: geen vaste lengte en afwisselend mutiple choice, ja/nee en open vragen. Wat zou hiervoor een mooi databasemodel zijn?

Mijn eerste ontwerp:

Wat volgens mij hier bij wel makkelijk is is dat je maar één tabel nodig hebt voor de vragen en een voor de antwoorden (aangezien php ook kan rekenen met een string enz.).

of


Wie heeft er misschien nog suggesties?

[The - DDD]

Wat is het verschil tussen ja/nee en multiple choice?

Alleen het aantal mogelijke antwoorden. Zie het ook zo.

Een tabel waarin alle vragen staan en het aantal mogelijke antwoorden.

Nu simpelweg het volgende doen: Sta ook toe dat iemand kan kiezen om een opmerking te maken bij een vraag. Maak dit een optie die niet verplicht is.

Dus maak een tabel met in ieder geval de volgende gegevens:
enquete ID; vraag ID en verdere gegevens; de vraag; het aantal mogelijke multiple choice velden; het aantal mogelijke open antwoorden (je wil misschien ook een opmerking en een antwoord kunnen geven op een open vraag).

Vervolgens nu twee tabellen met alle antwoord gegevens.

In de ene tabel komen alle antwoorden/opmerkingen te staan. In de andere komen de eventuele multiple coiche antwoorden te staan.

Je vind de antwoorden terug bij de vraag middels een key verwijzing, maar da's logisch.

[ACM]

* ACM gebruikte voor zijn enquete:
Ongeveer dit:
http://tweakers.net/~acm/pics/enquete_db.png

Weliswaar nog wel wat aanpassingen enzo, maar dit was het concept.

[Infinitive]

Ik heb voor school een boek moeten aanschaffen genaamd "Database Management Systems" van Raghu Ramakrishnan. Daarbij werd eerst een database in een ER-diagram gemodelleerd (Entity-relationship), en van daaruit een vertaalslag naar SQL.

Dat is best een interessante manier van modellen, vooral omdat je op deze manier niet echt van SQL afhankelijk bent en ook in je ontwerp nog geen concrete tabellen hoeft op te geven en dus ook relaties nog niet apart in tabellen (of verwerkt in de entiteit) hoeft weer te geven. Of je normalisatie doet op de SQL output of verwerkt in het diagram weet ik niet, bij dat hoofdstuk zijn we nog niet.

[Verwijderd]

Op donderdag 31 januari 2002 21:48 schreef Infinitive het volgende:
Ik heb voor school een boek moeten aanschaffen genaamd "Database Management Systems" van Raghu Ramakrishnan. Daarbij werd eerst een database in een ER-diagram gemodelleerd (Entity-relationship), en van daaruit een vertaalslag naar SQL.

Dat wat ik heb gemaakt is een (E)ERD... toch?

[Verwijderd]

Logisch of fysiek datamodel?

Ik zou denken aan de volgende entiteiten:
- gebruiker
- enquete
- vraag
- vraagtype ('open', 'choice' (1 antwoord uit reeks), 'multiple' (meerdere antwoorden uit reeks))
- antwoord
- antwoordreeks (naam voor reeks waarden voor 'choice' en / of 'multiple', bijv. 'ja/nee', '1 t/m 10', etc.)
- antwoordreekswaarden (waarden uit een reeks, bijv. 'ja', 'nee', '1', '2', '3', etc.)

HTH

[djc]

Ik zou zeggen een vraag-tbl met een binaire kolom open/closed en als ie open is mag ie de mogelijke antwoorden uit een tabel met antwoorden (op vraag-id) halen.