[MySQL] Tabel breed of diep?

[Lewis]

Ik heb een vragenlijst met 100 vragen die ik laat invullen door een aantal personen. Deze data wil ik opslaan in een MySQL-database. Ik maak een tabel "Vraagdata". Daarvoor ken ik 2 manieren:

1) Ik maak de tabel met 3 kolommen zodat de antwoorden onder elkaar komen in rijen:
Persoon | Vraagnummer | Antwoord

2) Ik maak de tabel door alles naast elkaar te zetten:
Persoon | Vraag_1 | Vraag_2 | .... | Vraag_100 |

De eerste manier geeft bij 1000 personen 100.000 rijen. De tweede manier geeft bij 1000 personen 1000 rijen die ieder 101 kolommen hebben.

De eerste manier lijkt minder gevoelig voor fouten. Je "insert" alles gewoon onder elkaar terwijl je bij de tweede manier moet gaan werken met "update".

Bij de eerste manier sla ik met 1000 personen ook 100.000 keer het nummer van de persoon en het nummer van de vraag op. Bij de tweede manier wordt alles 1 keer opgeslagen.

Welke heeft jullie voorkeur (als je niet kijkt naar het feit dat de 2e manier niet voldoet aan de eisen voor normalisatie) en waarom? Blijft die voorkeur hetzelfde bij meer of minder personen en meer of minder vragen?

[Voutloos]

Optie 1 is handiger als er een volgende enquete komt. Kan je gewoon met Vraag_ID 101-x verder gaan, zonder dat je je om de DB structure hoeft druk te maken.

[Lewis]

Je krijgt bij optie 1 wel ontzettend veel rijen en je slaat data dubbel op. Het is daar ook lastiger en tijdsintensiever om op te vragen welke vragen al zijn ingevuld. Is er überhaupt iemand die voor de tweede manier zou kiezen?

[Facer]

Optie 1... Als je nu alle antwoorden wilt na vraag 50.. Hoe wil je dat (eenvoudig) doen bij optie 2?

[Woy]

Een groot aantal rijen haalt voor een database niet veel uit, sterker nog daar is hij juist voor gemaakt. Een groot aantal kolommen is totaal niet handig om te onderhouden.

Als ik jou was zou ik een Tabel met Vragen maken waarin je de vragen stopt. dan maak je een aparte tabel voor de Antwoorden en nog weer een andere tabel voor de GegevenAntwoorden. En voor je PersoonsGegevens maak je natuurlijk ook nog een tabel aan.

[NMe]

Iedereen die een beetje serieus bezig is met databases zal je vertellen dat manier 1 veel bruikbaarder is. Ten eerste is het flexibeler, zoals Voutloos al zegt. Daarnaast is het zoals je zelf al zegt inderdaad minder foutgevoelig, en zelfs even snel als de andere manier, als je je indexen tenminste goed zet. 100.000 records is niet veel, daar draait een database zijn hand niet voor om.

Onderhoudbaarheid blijft het belangrijkste argument trouwens, zoals dat meestal het geval is bij normalisatiekwesties.

[JHS]

Ik zou het werkelijk anders doen en een tabel vragen maken, een tabel personen, een tabel antwoorden en een tabel antwoorden_personen, wat volgens mij een netjes genormaliseerde versie is ?

[NMe]

JHS schreef op vrijdag 24 februari 2006 @ 23:40:
Ik zou het werkelijk anders doen en een tabel vragen maken, een tabel personen, een tabel antwoorden en een tabel antwoorden_personen, wat volgens mij een netjes genormaliseerde versie is ?

Wat zou je in de antwoorden-tabel willen zetten wat niet in antwoorden_personen kan? Bij meerkeuze is het inderdaad handig wat je zegt, omdat mensen dan maar een klein aantal antwoorden kunnen geven, waarbij dus veel dezelfde antwoorden zullen zijn. Bij open vragen zou ik doen wat Lewis voorstelt in zijn topicstart.

[Lewis]

Ik zou zelf ook voor optie 1 gaan in combinatie met nog een aantal tabellen voor de vragen en de personen die ik hier niet genoemd heb, maar optie 2 schoot me te binnen toen ik ging nadenken over serverload en dataopslag.

Gebruikt de genormaliseerde methode omwille van de onderhoudbaarheid (wat inderdaad een heel belangrijk argument is) niet ten onrechte veel redundante gegevens terwijl het eigenlijk een methode is om dat te beperken?

En stel dat een dergelijke opdracht 1 keer, hooguit 2 keer voorkomt. Na de eerste keer optie 2 gebruikt te hebben zou men de database leeg kunnen gooien en bij de CREATE commando's voor de tabellen gewoon wat extra kolommen kunnen toevoegen. Prutswerk en heerlijk amateuristisch, maar het werkt wel. In phpmyadmin is de tabel vervolgens wat beter in te zien en te raadplegen voor de leek. Is er geen enkel voordeel dat optie 2 rechtvaardigt? Bij welke grote en omvang dan ook?

Wat zou je in de antwoorden-tabel willen zetten wat niet in antwoorden_personen kan? Bij meerkeuze is het inderdaad handig wat je zegt, omdat mensen dan maar een klein aantal antwoorden kunnen geven, waarbij dus veel dezelfde antwoorden zullen zijn.

Waarom zou een extra tabel handig zijn voor meerkeuzevragen? Ik noem de antwoorden altijd 1,2,3 ... Bij de latere verwerking weet ik wel welke soort antwoorden er bij welke vraag horen.

[Wolfboy]

Lewis schreef op zaterdag 25 februari 2006 @ 00:01:
Gebruikt de genormaliseerde methode omwille van de onderhoudbaarheid (wat inderdaad een heel belangrijk argument is) niet ten onrechte veel redundante gegevens terwijl het eigenlijk een methode is om dat te beperken?

Zie de post van JHS (en de toevoeging van -NMe-)

Dat is zeker de netste oplossing voor dit probleem

Maar, het kan idd wel een iets hogere serverload opleveren om elke keer de tabellen bij elkaar te gooien dmv. een join.

[JHS]

Wolfboy schreef op zaterdag 25 februari 2006 @ 00:07:
[...] Maar, het kan idd wel een iets hogere serverload opleveren om elke keer de tabellen bij elkaar te gooien dmv. een join.

Je moet op dit vlak niet overoptimaliseren in mijn ogen, en bovendien is dat met (fatsoenlijke) caching op te lossen .

[NMe]

JHS schreef op zaterdag 25 februari 2006 @ 00:10:
Je moet op dit vlak niet overoptimaliseren in mijn ogen, en bovendien is dat met (fatsoenlijke) caching op te lossen .

Goede indexering doet ook een hoop. Daarnaast natuurlijk nog steeds het feit dat 100k records niet veel is.

Lewis schreef op zaterdag 25 februari 2006 @ 00:01:
Waarom zou een extra tabel handig zijn voor meerkeuzevragen? Ik noem de antwoorden altijd 1,2,3 ... Bij de latere verwerking weet ik wel welke soort antwoorden er bij welke vraag horen.

Waar weet je dat dan van? Omdat dat hard in je code staat? Ook niet erg netjes natuurlijk. Als je er een tabel voor hebt in de database, dan kun je in één keer een compleet rapport uit je database trekken, netjes met vraag en antwoord bij elkaar. Eventueel met totalen en dergelijken.

[T-MOB]

Als ik zo vrij mag zijn om 2 aannames te doen:
1. Het gaat om een enkele enquête (en niet een systeem om meerdere enquêtes in te verwerken)
2. Je gebruikt de database alleen voor de opslag, als de gegevens binnen zijn dan gebruik je statistische software om de boel te analyseren.

Dan zou ik persoonlijk voor de niet genormaliseerde oplossing gaan. Niet zozeer omdat ik bang ben voor redundantie of het aantal rijen, maar vooral omdat het je een stuk makkelijker maakt. Als de dataverzameling klaar is kun je gewoon een tabledump importeren in je analysesoftware.
Bij de genormaliseerde oplossing wordt het opvragen van de data in deze vorm een stuk complexer. In SQL wordt het een JOIN festijn waar je u tegen zegt. Zelfs met behulp van een script wordt het een oplossing is die specifiek is voor de het huidige onderzoek (en in elk geval minder performant, maar dat is niet zo'n heel groot argument voor een actie die hooguit enkele keren wordt uitgevoerd). Het punt is dus dat je onderzoeksgegevens eigenlijk altijd terug wil zien als 1 "regel" data per respondent. Data opslaan in een andere vorm is dan gewoon niet handig.

De flexibiliteit die je opgeeft door niet te normaliseren is verder niet zo relevant. Een vraag toevoegen aan een enquête "doe je niet", wetenschappelijk gezien dan. Met een nieuwe vraag wordt het een andere enquête en kun je de gegevens niet zomaar onderling vergelijken.