Mailinglisten-Archive |
Danke für die vielen Tipps! >Wie wäre es, wenn du einfach das Berechnungsskript einmal ausführst bzw. >ausführen lässt (zB. per Cron-Job) und die Ergebnisse in einer Extra-Tabelle >speicherst. Wäre das nicht eine sinnvolle Daten-Redundanz? >Dann musst du nicht jedesmal alles komplett neu berechnen und neue >Ergebnisse gibts ja eh nur einmal direkt nach den Spielen, oder? Die Idee mit der Extra-Tabelle ist prima! Das bietet sich sogar an, weil ich die Spielergebnisse online in die Datenbank eintrage. Da brauche ich cron-job, sondern kann kann sofort die Tipps auswerten und die Rangliste erstellen. Da ist es mir recht egal, ob es dann laengere Zeit zum Berechnen braucht. Warum man auf so simple Ideen manchmal nicht selber kommt! Danke! >na-ja, >wenn man mal von der Anzahl der Datensaetze ausgeht, sollte >das doch wesentlich flotter ablaufen ... >Was haeltst Du davon, wenn Du mal ein paar Beispieldaten >offenlegst? Damit man z.B. sieht, wie Spiele, Tips und User >angelegt sind ... Werde ich später machen, weil ich natuerlich noch dazulernen moechte! >Das haengt von Deiner Datenbankstruktur ab. ;-) >Wichtig ist z.B.: >- richtige Indices auf die Tabellen zu setzen, damit MySQL schneller auf >die Daten zugreifen kann. (= Datenbankoptimierung) >- die Tabellenstruktur gerade bei hohen Datenmengen sehr gut durchdacht >zu haben, damit auf die Daten optimal und damit schneller zugegriffen >werden kann. (= Datenbankoptimierung) >- Datensaetze mit IDs zu versehen und ueber IDs zu verknuepfen, um so >die Datenmengen zu reduzieren, die bei der Verknuepfung von >Datensaetzen gehandhabt werden muessen. (= Datenbankoptimierung) >- keine "select * from tabelle..."-Befehle ausfuehren, sondern nur die >Felder auszulesen, die tatsaechlich benoetigt werden, um nicht >unnoetige Datenmengen auszulesen und damit die Laufzeit unnoetig zu >verlaengern. (SQL-Optimierung) >- zu ueberlegen, welche SQL-Befehle man absetzt, d.h. z.B. a) einen >Monster-Befehl, der alles auf einmal holt, oder b) vielleicht erst >einen, der die IDs holt, und dann mehrere, die mit diesen IDs die Daten >holen. Variante b) kann die zu behandelnden Datenmengen durchaus >deutlich reduzieren und damit die Laufzeit deutlich verkuerzen. >(SQL-/Skript-Optimierung) >- bestimmte Daten nicht immer beim Aufruf zur Laufzeit neu zu berechnen, >sondern direkt bei der Erfassung einmal zu berechnen und dann in der >Datenbank abzulegen und bei jedem anschliessenden Aufruf nur noch aus >der Datenbank auszulesen. Danke fuer die ganzen Tipps. Datenbankoptimierung habe ich soweit ich kann schon durchgefuehrt. Mein Hauptproblem ist das Auslesen der Daten und das optimale Berechnen (SQL-/Skript-Optimierung). Anfangs hatte ich viel mit "select * from..." gearbeitet, da habe ich sogar schon die 8MB memory_limit überschritten. >oops, >der Spieler kann Tipps zu jeder beliebigen Paarung abgeben, >also ein Tippschein/Formular mit 3600 Radiobutton (g,u,v,), >oder wie muss man sich das vorstellen ... <gruebel> Ganz einfach: Es können insgesamt 18 Ligen getippt werden. Insgesamt sind das ca. 1200 Spielpaarungen. Wenn da Woche für Woche ca. 10 Spieler pro Spielpaarung tippen, komme ich dann auf 12000 Tipps. Ich werde in den nächsten Tagen Quellcode und Datenbankstrukturen bekannt geben. Würde mich um ein bißchen Unterstützung und weitere Ideen sehr freuen. grüße frank
php::bar PHP Wiki - Listenarchive