twee tabellen, of tabel per jaartal?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Eric T

Eric T

21/12/2014 22:02:27
Quote Anchor link
Wie oh wie heeft zinvol advies...

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
 
PHP hulp

PHP hulp

29/03/2024 09:05:40
 
- Ariën  -
Beheerder

- Ariën -

21/12/2014 22:09:43
Quote Anchor link
Nooit databases, tabellen of velden laten doornummeren vanwege een jaartal of andere aantallen.

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).
 
Eric T

Eric T

21/12/2014 22:17:04
Quote Anchor link
Hoi Aar,

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
 
Pipo Clown

Pipo Clown

21/12/2014 22:24:06
Quote Anchor link
Mijn persoonlijke voorkeur gaat uit naar een tabel per seizoen.
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.
 
- Ariën  -
Beheerder

- Ariën -

21/12/2014 22:26:33
Quote Anchor link
Als je twee of meer tabellen hebt, hoe wil jij dan nog makkelijk statistieken kunnen uitrekenen?

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 -
 
Eric T

Eric T

21/12/2014 22:35:11
Quote Anchor link
Wel... statistieken...dat is een punt.
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
 
- Ariën  -
Beheerder

- Ariën -

21/12/2014 22:47:42
Quote Anchor link
Niks nadenken, gewoon doen. Je kan zo prima filteren op leden van dit seizoen, en tellingen maken of je nu meer deelnemers hebt dan vorig jaar etc...

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.
 
Eric T

Eric T

21/12/2014 22:51:38
Quote Anchor link
Dat is inderdaad precies wat we willen...(of iem vaker heeft mee gedaan e.d.)
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).
 
- Ariën  -
Beheerder

- Ariën -

21/12/2014 22:56:00
Quote Anchor link
Scheiden is nergens voor nodig, als je doelt op meerdere tabellen. Ik ken een forum die inmiddels iets van 50 GB groot is en die hun inhoud ook niet 'archiveren' in een aparte tabel.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

22/12/2014 10:11:27
Quote Anchor link
Aar heeft gelijk Eric. Volg het maar gewoon zou ik zeggen

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
 
Eric T

Eric T

22/12/2014 11:01:00
Quote Anchor link
Hahaha :-) Dat noem ik nog eens een briljant argument :-)
Thanks. Ik zal het inderdaad met 1 tabel gaan doen.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

22/12/2014 17:27:18
Quote Anchor link
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
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.