twee tabellen, of tabel per jaartal?
Situatie:
Elk jaar (seizoen) wordt er een tabel bij gemaakt met deelnemers.
De keuze bij een nieuw seizoen:
Bij een nieuw seizoen heb ik de volgende keuzes:
a) ik laat de tabel ongemoeid en vul nieuwe deelnemers bij met een ander seizoen-nummer,
alles in 1 tabel dus.
b) ik geef élk seizoen een eigen tabel
c) ik hanteer twee tabellen: 1 met het huidige seizoen (waarin veel interactie is),
en 1 met alle oudere seizoenen (waarin weinig interactie is).
Vraag:
Het een zal voordelen hebben boven het andere kwa snelheid, overzicht en mogelijk zelfs
programmeerlengte.
Maar kan iemand uit ervaring misschien zeggen wat de meest praktische manier is en met welke voordelen?
Ikzelf zou op dit moment kiezen voor optie c)...
Alvast dank voor het meedenken...
vr gr Eric
Gewoon in de deelnemerstabel de deelnemers indelen op datum van start seizoen.
Toevoeging op 21/12/2014 22:11:43:
Eric T op 21/12/2014 22:02:27:
Het een zal voordelen hebben boven het andere kwa snelheid, overzicht en mogelijk zelfs programmeerlengte.
Het ligt eraan hoe je programmeert. Verder kan MySQL in een tabel wel miljoenen records, totdat je misschien even een INDEX op je veld moet leggen om de snelheid hoog te houden.
Dus ik kies voor a).
Dank voor je reactie. Kun je uitleggen waarom? Dat is wat ik zo graag wil weten :-)
Waarom ikzelf nu denk dat dat niet handig is (maar mogelijk dus helemaal verkeerd benaderd?), is
dat ik denk dat als we 20 jaar verder zijn, hebben we ongeveer 6000 regels in die tabel
(met ongeveer elk 20 kolommen aan gegevens). Dat is behoorlijk wat....
Gevoelsmatig zou ik dan geneigd zijn te zeggen dat raadplegen van die ene complete tabel
steeds trager wordt... vandaar voor mij nu optie c.
Dus eigenlijk ben ik op zoek naar een goede onderbouwing waarom welke keuze...:-)
-- update 22:20 --
Ah, zie nu je update erbij :-) dankje!
Gewijzigd op 21/12/2014 22:20:31 door Eric T
Maar dan wel alleen voor de variabele gegevens.
Zelf heb ik een systeem geschreven voor de urenregistratie op het werk, daar maak ik ieder jaar een nieuwe tabel aan. In de urenregistratie tebel komen dus alleen de uren en een id van de gebruiker.
In jouw geval zou dit een lid-ID zijn.
Vergeet niet dat computers al jaren SNEL zijn dus waarom zou je twijfelen over 6000 regels in een tabel? Ikzelf heb treininformatie (f.y.i: treinnummers)in een tabel staan voor een hoop seizoenen, en die is inmiddels al iets van > 80.000 items groot, en geeft geen krimp!
Gewijzigd op 21/12/2014 22:28:21 door - Ariën -
In mijn geval zijn statistieken niet nodig...
Voor mij zijn de oudere(!) gegevens alleen maar nodig voor een deelnemer die
nieuwsgierig is naar zijn oude gegevens. Of uitzonderlijk misschien de administrator.
Mogelijk 1 of max 5x per seizoen schat ik in.
Het huidige seizoen daarentegen, wordt constant gebruikt door voornamelijk de administratie...
Maar dit ter info...
Maar als ik het goed begrijp is het een niet echt veel fouter dan het andere,
maar gewoon erg afhankelijk van waar het voor dient...uiteraard met een vooruitziende blik
meegenomen in de afweging. Toch? Of zie ik het fout?
1 tabel is programmeertechnisch wel weer een stuk eenvoudiger kwa programmeren...
En wat Aar zegt over snelheid en indexeren is natuurlijk ook zo....
Ik moet er nog even over denken :-)
Gewijzigd op 21/12/2014 22:36:14 door Eric T
En zelfs kan je met een tabel extra ook nog eens bijhouden of een deelnemer vaker heeft meegedaan. Je slaat dan alle seizoenen van alle deelnemers op in de tabel deelnemers_seizoenen, en die koppel je aan de tabel met deelnemers.
Als je meer dezelfde tabellen voor dezelfde doeleinden gebruikt wordt het sowieoso slecht onderhoudbaar.
Weet je... ik denk dat dit gewoon wel de meest eenvoudige en overzichtelijke manier is.
En als het echt invloed zou gaan hebben op de snelheid in de loop der jaren, dan kan het altijd nog gescheiden worden...(nog los van het feit dat computers en internet over 20 jaar naar ik aanneem weer een stuk sneller zullen zijn).
Je sprak jezelf al tegen met 'als ik ooit...'
Nu draaien we het even om: nou wil je over vijf jaar alle mogelijke info over bijvoorbeeld een speler die in die vijf jaar een topspeler is geworden ..
Zou wat zijn als je dan nee moest verkopen
Gewijzigd op 22/12/2014 10:20:30 door Frank Nietbelangrijk
Thanks. Ik zal het inderdaad met 1 tabel gaan doen.
Aar:
Het ligt eraan hoe je programmeert. Verder kan MySQL in een tabel wel miljoenen records, totdat je misschien even een INDEX op je veld moet leggen om de snelheid hoog te houden.
Indexen zijn onderdeel van een goed data model, die ga je niet aanbrengen om dat je veel rijen begint te krijgen.
Overigens is het opslitsen van tabellen de laatste jaren niet meer nodig, je hebt daar tabel partitioning voor. Dit is trouwens niet zinvol voor een tabel met 6000 records.
Gewijzigd op 22/12/2014 17:28:02 door Ger van Steenderen