samurai wrote:Auf dauer gesehen macht es mehr Sinn die Daten in eigene Tabellen zu speichern,
Nein, das macht nie einen Sinn. Dann braucht man auch kein SQL zu verwenden, da Dir sowieso kaum die mächtigen Funktionen einer relationalen Datenbank zur Verfügung stehen.
samurai wrote: da so in 1-2 Jahren wahrscheinlich über 10 Mio. Datensätze in einer Tablle wären, was a) für Unübersicht sorgen würde und b) die Select-Abfrage deutlich verlangsamen würde wenn ich nur nach Daten eines einzigen Nutzers suche (was oft der Fall ist)
Na und? Dafür ist MySQL doch gedacht. Die anderen beiden haben Dir ja schon entsprechend geantwortet und ich bin mir zudem völlig sicher, dass Du das "aus dem Bauch heraus" glaubst, statt getestet zu haben (da würdest Du Dich wundern, wie schnell MySQL ist, wenn man die entsprechenden Felder mit einem Index versieht.
samurai wrote: Es wäre also total verkorkst es so zu machen, wie du es vorgeschlagen hast.
Nein, total verkorkst ist es jetzt, aber es ließe sich ja zur Zeit noch relativ schnell umstellen. Je mehr Du Coding verschwendest, um das falsche Datendesign zu verwirklichen, umso weniger wirst Du bereit sein, es zu ändern. Und Du wirst auf Dauer nicht um eine Änderung herum kommen, denn genau Dein aktuelles Problem wird jämmerlich eingehen, wenn Du wirklich 10 Millionen Datensätze auf diese Weise gruppieren und addieren willst.
Hättest Du es richtig programmiert, würde ein einziges(!) SQL-Statement die Lösung bringen - und das ziemlich flott, auch bei Millionen von Datensätzen:
- Code: Select all
SELECT `Datum`, Sum(`Kosten`) As Summe FROM `Tabelle` GROUP By `Datum` ORDER ASC By `Datum`
Fertig! Anschließend kannst Du die Treffermenge abklappern und ausgeben.
Wieviele Zeilen brauchst Du dafür - und vor allem, wieviel Rechenzeit brauchst Du dafür? Je mehr Tabellen und Datensätze Du abklappern mußt (Du mußt ja Dein Array erst einmal sukzessive füllen) und anschließend sortieren (holla die Waldfee bei 10 Millionen Sätzen) und dann die Teilsummen bilden - da wird das PHP Script stundenlang laufen, wenn es nicht durch irgendwelche Restriktionen bereits vorher abgebrochen wird.
Und ein Select auf einzelne Datensätze eines Kunden dauert trotz der 10 Millionen Datensätze nicht wesentlich länger, als wenn die Sätze auf 1000 Tabellen verteilt sind, dafür sorgt der INDEX der MySQL Engine.
Wenn Du das Datendesign (was das Wort nicht verdient) so läßt, wirst Du an allen Ecken und Enden immer wieder normale Datenbankfunktionen in PHP programmieren müssen, weil sie wegen des falschen Designs nicht in MySQL realisierbar sind. Und sei es nur die Anforderung, die Kunden alphabetisch zu sortieren, oder den Kunden mit dem höchsten Tagesumsatz zu finden, oder den Kunden, der den letzten Artikel vom Typ XYZ gekauft hat, oder oder oder - alles ganz normale Anforderungen, die mit Deinem Datenmodell nicht mit SQL-MItteln lösbar sind - und dabei ist es doch genau die Aufgabe von SQL, diese Dinge zu ermitteln.
Ich verstehe das auch nicht, zum einen fragst Du hier nach Hilfe, wie man etwas bestimmtes programmiert, aber wenn dann wirklich ein ernst gemeinter Hinweis kommt, der nicht nur die Lösung präsentiert sondern auch noch das Datenmodell in die richtige Richtung korrigiert - da interessiert es Dich nicht mehr und Du "machst besserwisserisch" auf cool - dabei fehlt Dir mit absoluter Sicherheit der notwendige Background, um das wirklich beurteilen zu können. Verlass Dich dich doch mal darauf, dass diese Ratschläge nicht einfach "aus dem Bauch" kommen sondern auf jahrelanger Erfahrung beruhen. Du wirst es nicht bereuen - aber wenn Du es läßt, wirst Du es bereuen, das ist ganz sicher, vor allem wenn es stimmt und in wenigen Jahren solche Datenmengen vorliegen. Dann bist Du ohne adäquate Unterstützung durch SQL aufgeschmissen - und da kann man dann gar nichts mehr machen, die Anwendung wird dann einfach durch die Datenmenge erdrückt.
