Split database verstandig?

Door Wout van der Burg op 28-03-2011 08:31

1.516 views

Hallo,

Mijn collega heeft een urenregistratiesysteem ontwikkeld, waar men hun activiteiten kan registreren m.b.v. een MySQL database.
Nu is er voor, bijvoorbeeld dit jaar een tabel aangemaakt "registratie_2011".
Voor volgend jaar zal automatisch een tabel worden aangemaakt "registratie_2012".

Is dit nu wel verstandig, omdat men eigenlijk wel door jaren heen informatie wil extraheren uit de database?

Per tabel zal gerekend moeten worden op 10.000 tot 15.000 records. Kan MySQL met gemak veel meer records aan en zal ik snelheidsverlies bemerken als ik, pak m beet, 3 van deze tabellen samenvoeg tot één?

- Ariën -

28-03-2011 09:56 gewijzigd op 28-03-2011 09:57

Nu is er voor, bijvoorbeeld dit jaar een tabel aangemaakt "registratie_2011".
Voor volgend jaar zal automatisch een tabel worden aangemaakt "registratie_2012".

Dit is dus echt behoorlijk fout. Je moet aantallen van entiteiten nooit vastleggen in je database-model. Op die manier maak je het erg lastig om queries te maken waarbij je de andere tabellen ermee betrekt. Op grote schaal kan dit zelfs ook trager werken.

MySQL heeft met 10.000 records geen problemen, met 100.000 zelfs niet, en met 1.000.000 records lacht hij er nog steeds om. Wel is het handig om indexés te plaatsen op de velden die het meeste geraadpleegd worden.

Wout van der Burg

28-03-2011 10:37

Bedankt voor je reactie.
Dit dacht ik dus ook inderdaad, omdat het gewoon totaal niet handig is, om over een aantal dezelfde tabellen, enkel met verschillende periodes een view te leggen. Dit komt de prestatie zeker niet ten goede.
Nu heb ik even een stok achter de deur om te overtuigen, dus bedankt!

? Onbekende gebruiker

28-03-2011 10:59

Je kunt wel data afsplitsen, maar meestal doe je dat met erg oude data die je niet meer nodig hebt.

Wout van der Burg

28-03-2011 11:03

Juistem, en die zou je natuurlijk "registratie_archief" kunnen noemen :)

Reageren

Inloggen om te reageren