[MySQL]database structuur?

[EntonoX]

Best medetweakers,

Ik heb een klein probleem/vraagje. Ik ben op dit moment bezig met het opbouwen van een database voor het opslaan van loggegevens. Deze loggegevens bevatten een unitnummer (van welke logunit de loggegevens vandaan komen) en een aantal gegevens velden.
Nu heb ik gelezen dat tabellen maximaal 4Gb groot mogen/kunnen worden. Nu zit ik dus met de vraag of het makkelijker/ sneller is om in plaats van één tabel voor alle loggegevens, alle units hun eigen tabel te geven. Hierdoor heb ik dus meer opslag capaciteit voor de gegevens en ben ik sneller met queries, toch? De tabellen zullen in het eerste jaar niet zo groot worden, maar je moet een beetje in de toekomst denken niewaar?

En is het dan niet verstandig om de loggegevens tabellen gelijk in een heel aparte eigen database te zetten? of is dit weer omslachtiger/langzamer met queries welke uit de andere database moeten komen?

Wie kan me wat raad geven? en ja ik heb al her en der gezocht hier maar kan geen passend antwoord vinden...

[ Voor 4% gewijzigd door EntonoX op 30-10-2006 16:18 ]

[MBV]

Als je netjes je software ontwerpt (met gescheiden database-laag) kan je dat altijd doen zodra het nodig is. Nu is het nog niet nodig, dus kan je het beter niet doen. Zodra het nodig wordt, kan je dat bij een net ontwerp eenvoudig toevoegen

[4VAlien]

Hoe snel denk je die 4GB vol te hebben? Jaren, maanden of dagen?

[webinn]

tegen dat je 4 gb vol hebt, zullen we wel een paar jaar verder zijn En tegen dan zal mysql wel weer grotere tables ondersteunen...

Je kan ook je oude gegevens archiveren in een andere table

[ToasterxD]

Normaliseren.

[EntonoX]

ToasterxD schreef op maandag 30 oktober 2006 @ 16:42:
Normaliseren.

Uiteraard maar dat heb ik ook gedaan, alle unit gegevens staan in een eigen tabel, sleutels toegekend, etc. en de loggegevens tabel bevat weer het unitnummer als index.

4VAlien schreef op maandag 30 oktober 2006 @ 16:39:
Hoe snel denk je die 4GB vol te hebben? Jaren, maanden of dagen?

Dat zal meer op enkelen maanden to jaren aankomen zover ik nu kan zien. Maar vooruit zien is regeren....

MBV schreef op maandag 30 oktober 2006 @ 16:36:
Als je netjes je software ontwerpt (met gescheiden database-laag) kan je dat altijd doen zodra het nodig is. Nu is het nog niet nodig, dus kan je het beter niet doen. Zodra het nodig wordt, kan je dat bij een net ontwerp eenvoudig toevoegen

Uiteraard, het enig wat aangepast hoeft te worden zijn de queries naar een andere database/tabel, dus technisch niet echt moeilijk om aan te passen.

[Varienaja]

EntonoX schreef op maandag 30 oktober 2006 @ 16:18:
Nu heb ik gelezen dat tabellen maximaal 4Gb groot mogen/kunnen worden. Nu zit ik dus met de vraag of het makkelijker/ sneller is om in plaats van één tabel voor alle loggegevens, alle units hun eigen tabel te geven.

Snelheidsverschil merk je niet (tenzij je geen fatsoenlijke indices maakt).
Makkelijker is het *zeker niet*.

Mooi alles in 1 tabel duwen dus! Handig trouwens dat je nu al weet dat ze maximaal 4GB worden, dan hoef je je al helemaal niet meer druk te maken over de toekomst. Je kan direct nu al 4GB testgegevens genereren en kijken of 't fatsoenlijk werkt, en dan voor eeuwig zeker zijn van je zaak.

[RobIII]

Varienaja schreef op maandag 30 oktober 2006 @ 17:12:
Handig trouwens dat je nu al weet dat ze maximaal 4GB worden, dan hoef je je al helemaal niet meer druk te maken over de toekomst. Je kan direct nu al 4GB testgegevens genereren en kijken of 't fatsoenlijk werkt, en dan voor eeuwig zeker zijn van je zaak.

Nee, hij zegt dat MySQL niet groter dan 4GB ondersteunt, maar dat zijn hoeveelheid gegevens wel degelijk (ooit, sometime) over de 4GB gegevens grens kan gaan en dus probeert TS dat te voorzien om problemen te voorkomen

[EntonoX]

RobIII schreef op maandag 30 oktober 2006 @ 18:23:
[...]

Nee, hij zegt dat MySQL niet groter dan 4GB ondersteunt, maar dat zijn hoeveelheid gegevens wel degelijk (ooit, sometime) over de 4GB gegevens grens kan gaan en dus probeert TS dat te voorzien om problemen te voorkomen

juist helemaal gelijk! ik zit nog steeds te twijfelen, want als ik de loggegevens daadwerkelijk ga opdelen krijg ik dus veel tabellen ~300 to 500 misschien wel omdat er zoveel logunits zijn. Dus wat is dan wijsheid in zo`n geval, opdelen of in één tabel?

Mn gevoel zegt, opdelen in tabellen in een aparte database omdat dit het gewoon overzichtelijker maakt, plus dat je volgens mij een quotum kunt stellen aan de tabelgrootte waardoor je de hoeveelheid loggegevens per tabel kan beinvloeden.

toch?

[NetForce1]

Kun je de gegevens niet aggregeren per maand/jaar oid?

[MBV]

Ik blijf erbij dat je je daar nu nog geen zorgen om hoeft te maken. Zodra het probleem begint te spelen kan je daar dankzij je abstractie-laag eenvoudig de queries aanpassen. Je maakt het nu alleen maar moeilijk voor jezelf

[EntonoX]

MBV schreef op maandag 30 oktober 2006 @ 22:17:
Ik blijf erbij dat je je daar nu nog geen zorgen om hoeft te maken. Zodra het probleem begint te spelen kan je daar dankzij je abstractie-laag eenvoudig de queries aanpassen. Je maakt het nu alleen maar moeilijk voor jezelf

Ok, dat is inderdaad wel zo ja. Ik denk dat ik het dan voorloppig wel even zo laat en wanneer er echt bakken met info binnenkomen dat ik dan de database aanpas. Alvast bedankt voor de tips iedereen!

[djluc]

Je zou wel kunnen overwegen om je database queries e.d. allemaal in 1 centrale plaats te beheren. Vanuit je business logic roep je dan bijvoorbeeld aan:

PHP:

$dataVanStartTotEnd=$dataObj->getAllLogEnties($startdate, $enddate);

Dan hoeft je business logic niet te weten welke tabellen uberhaupt aanwezig zijn. Of je die data door monniken in laat tikken of dat ze via internet vanaf een andere server komen. Niemand weet het, en het maakt ook niets uit.

[MBV]

Dat bedoelde ik met een goed ontwerp

[BikkelZ]

Je kunt met MySQL 5 en de juiste DB-engine ook met triggers en dat soort zaken werken. Dat je boven de miljoen records een tabel aanmaakt met bijvoorbeeld een datum in de naam en daar de oudste 500.000 naar toe schrijft iedere keer. Maar pas op, dat kan ook ten koste gaan van je performance als je het niet goed doet, en misschien moet je er helemaal vanaf stappen en alsnog het op scriptniveau oplossen, dit zijn geen dingen die ik uitgebreid getest heb.


Maar in dat geval hoef je helemaal niets aan te passen, want je kunt zelfs de scripts die ze later weer uit moeten laten lezen eerst laten uitlezen welke databases er zijn en welke voldoen aan het naam_datum formaat en aan de hand daarvan een while loop doorlopen die de databases weer query'd.