Bewältigt MySQL gro ße Datenmengen ?
-
Habe folgendes Problem.
In meiner Datenbank für mein Programm (Pizzabringdienst Bestellverwaltung) sollen die Bestellungen nur für den aktuellen Tag gespeichert werden.
Kein Problem, dann lösche ich die Datensätze in der Bestellungs Tabelle usw.
Das Problem ist, das ich eine Artikelverkaufsstatistik benötige.
(Für jeden Artikel Anzahl verkaufte Stück pro Tag)
Habe mir nun überlegt eine Tabelle Artikelstatistik anzulegen, wo ich jeden Tag für jeden Artikel (zur Zeit ca.400) einen Datensatz anlege(Datum,Artikelnr,menge).
Das würde ja ohne Probleme funktionieren...
Nur wenn ich mir dann überlege wie diese Tabelle nach einem Jahr aussehen würde (wohl ne ganze Menge Einträge) habe ich bedenken ob meine Datenbank (MySQL) das geschwindigkeitstechnisch noch gebacken bekommt.
Kann man das irgendwie eleganter lösen ? oder stellen solch große Tabellen im normalfall kein Problem dar ?
-
hi,
ich glaube kaum, dass du mit deinem Pizzabringdienst an die Grenzen von MySql stossen wirst! Da würde ich mir keine Sorgen machen...
-
400 Einträge * 365 Tage * ~500 Bytes/Eintrag = 69MB im Jahr
Ich denke das sollte selbst ein kleinerer Rechner schaffen. Die Frage ist natürlich immer wie lange so ein System läuft. Wenn das erstmal 20 Jahre in Betrieb ist...aber bis dahin kann man wohl einen (vielfach) besseren Rechner zu billigen Preisen bekommen und das Problem wieder in die Zukunft verlegen.
Probleme würde ich nur sehen, wenn in dieser Artikelstatistik sehr oft am Tag SELECTs ausgeführt werden, aber ich denke das ist hier nicht der Fall, oder?
MfG SideWinder
-
Ich habe hier Datenbanken mit mehreren Millionen einträgen die sehr oft abgefragt werden. (Ist aber ein 4 x 2,7 GHZ XEON mit 4 GB Speicher)
Es kommt immer auf dein Design an.Wenn die Tabellen wenige Einträge haben das sind sie auch schnell.
Du könntest z.B. eine Tabelle pro Monat machen.Diese Tabellen sollte aber nicht für den Bestellvorgang verwendet werden.
-
Danke für die Antworten.
Dann bin ich ja beruhigt.
Es würden pro Tag so ca. 150-200 Einträge dazukommen (Nicht verkaufte Artikel brauche ich ja nicht speichern).Probleme würde ich nur sehen, wenn in dieser Artikelstatistik sehr oft am Tag SELECTs ausgeführt werden, aber ich denke das ist hier nicht der Fall, oder?
Es werden nur SELECTs ausgeführt, wenn sich jemand die Artikelstatistik für den Tag bzw den Monat anschauen will bzw zur Monatsabrechnung, wenn die Statistik ausgedruckt wird.
Warum gibt es bei vielen SELECTs dann Probleme ?Du könntest z.B. eine Tabelle pro Monat machen.
Diese Tabellen sollte aber nicht für den Bestellvorgang verwendet werden.
Habe ich mir auch schon so überlegt jeweils eine neue Tabelle aus Monatsnamen und Jahreszahl zu bilden.
Die Artikel werden auch nur in die Artikelstatistik übernommen, wenn die Bestellung einem Fahrer zugeordnet und bestätigt (ausgetragen) wurde.Das Programm, das bis jetzt dort läuft verwendet nur Monatsnamen für den Bestellvorgang, was dazu führt das man bis zum 01.01. eines neuen Jahres umbedingt die alten Bestellungen gelöscht haben sollte...
(War ne ...eiß Arbeit (Access DB Passwort knacken und Löschabfragen schreiben ...)
-
Wenn die Tabellen wenige Einträge haben das sind sie auch schnell.
Du könntest z.B. eine Tabelle pro Monat machen.Findest du sowas tatäschlich gut? Technisch wärs auch mit bloß einer Tabelle hier kein Problem und warum unnötig gegen Strukturregeln verstoßen?
MfG SideWinder
-
Ich habe sowas bei Tabellen mit mehreren Millionen Einträgen.
Da ist es unausweichlich.Bei o.a. ist es nicht notwendig aber er sollte die Alternativen kennen.