maar dan krijg ik voor iedere deelnemer die een test doet 10 entries en dus een enorme tabel als er 10000 man meedoet.....en ik moet veel queries doen op deze tabel, om gemiddelden te berekenen per onderdeel, per functie van deelnemer, etc...
heeft iemand een idee of ik iets over het hoofd zie of een denkfout maak?
Ziet er goed uit en ik zie niet in waarom dit problemen op zou moeten leveren. In tegendeel, nu kun je prachtige indexen maken op de resultaten en daar snel de gewenste data uithalen.
En 10 x 10.000 records = 100.000, dat is dus nog steeds 10x niks... Zet daar eens 1000x zoveel in, dan heb je het ergens over.
in·dex (de ~ (m.), ~en/indices)
1 register, inhoudsopgave
2 'index librorum prohibitorum', eertijds lijst van door de roomse curie verboden boeken
3 toegevoegd cijfertje of lettertje dat een grootheid in een bepaalde categorie rangschikt
4 verhoudingscijfer
5 [Belg., niet alg.] prijsindex => prijsindexcijfer
Wanneer je goede indexen aanmaakt en gebruikt, kun je queries wel een factor 1000 versnellen. Doe je dit echter verkeerd, kun je de complete database op zijn bek laten gaan... Performance is dan ver te zoeken.
Maar begin met een goed datamodel, dat is de basis voor ieder goed systeem Ga je nu nog niet druk maken over indexen, je hebt op dit moment geen enkel probleem met de perfomance.
En wanneer je geen problemen hebt, ga je ook niet op zoek naar oplossingen. Dat wordt ook lastig, een niet-bestaand probleem kun je niet oplossen.
Edit: Wanneer je noodgedwongen écht MySQL wilt gaan gebruiken, gebruik dan wel de innoDB-engine en vergeet niet om de juiste foreign key's aan te maken! Gekloot met MyISAM zou ik mijn grootste vijand nog niet aanraden...
Wanneer je noodgedwongen écht MySQL wilt gaan gebruiken
Noodgedwongen is dit dat ook de meest populaire web database ;D
'noodgedwongen' mag je ook lezen als 'weet niet dat er andere/betere bestaan'...
Hét grote probleem, en direct ook voordeel voor beginnners, is dat MySQL de grootste fouten nog vergeeft. Dat jij een stuk tekst van 300 karakters in een veld van 255 karakters stopt, daar maalt MySQL niet om. In eerste instantie ziet de programmeur ook niet dat er e.e.a. goed fout gaat, maar later blijkt toch een deel van de data pleite te zijn... Maar ja, dan is het systeem al zo ver af dat men niet meer overstapt op een database die direct een keiharde foutmelding geeft. En dat zou je wel mogen verwachten! Hierdoor lijkt MySQL in eerste instantie een hele leuke database, maar onder motorkap zit een draak van een engine verstopt. Vroeg of laat krijg je daarmee te maken.
Wanneer je de boel instelt op STRICT-mode en je gebruikt versie 5 of hoger, wordt het al wel een stuk beter, maar het is nog steeds niet van het niveau zoals je dat van andere databases bent gewend.
Nu wordt het wel een beetje simpel een bash-MySQL-topic...
Wanneer je de boel instelt op STRICT-mode en je gebruikt versie 5 of hoger, wordt het al wel een stuk beter, maar het is nog steeds niet van het niveau zoals je dat van andere databases bent gewend.
Ik ben het met je eens dat versie 5 een hele verbetering is. Ik heb ook wel eens wat gelezen over rare fouten in MySQL. Ook heb ik eens een lijstje gezien met fouten/rare dingen in PostGreSQL.
Maar ik zeg niet voor niets "web database". Ik ben er namelijk van overtuigt dat PostGreSQL meer een echte database wil zijn. MySQL is deze weg sinds versie 5 ook ingeslagen volgens mij.
Maar het is maar net wat je gewend bent en waar je de beschikking over hebt, dit is meestal MySQL.
