Hallo Forum,
Erst einmal: Ich stehe bei MySQL vor genau dem Problem, was in http://www.mysql.de/doc/de/example-Maximum-column-group-row.html beschrieben wird.
Ich programmiere gerade mein eigenes Forum/Board mit PHP und MySQL. [1]
Dabei will in der Board-Ansicht ich das Datum des letzten Postings (mit GROUP BY kein Problem) und den Autor des letzten Postings anzeigen. Und hier ist der Knackpunkt: Das, was im MySQL-Manual als ausweg beschrieben wird, gefällt mir alles nicht. Ich setze nämlich so im Endeffekt eine ganze Menge Datenbankabfragen an die Datenbank ab. (Da ich PHP verwende, muss ich für jeden Befehl ein mysql_query starten) Das kostet Performance. Ich habe an einigen anderen Stellen die Anzahl der DB-Abfragen, die das Script produziert, von 22 auf 10 reduziert; und 10 kommt mir schon ziemlich viel vor. (und bei dieser Reduzierung war ein _deutlicher_ Performanceanstieg spürbar gewesen)
Dann kommt wieder so ein Punkt: Bei der Forumsansicht hole ich mir einfach die Liste aller Postings und bau mir dann im Speicher daraus den Thread-Baum. Das geht recht flott - allerdings möchte ich dem Benutzer auch anbieten, dass er den Thread-Baum anders sortieren kann. (das Sortieren wird in der Datenbank erledigt) Ich will zum Beispiel auch die Möglichkeit anbieten, dass man die Threads nach dem letzten Posting sortieren kann. Mit MySQL könnte ich das auf zwei Weisen lösen: a) ich hole mir zuerst die Thread-Liste mit einem GROUP BY auf die Postings (um das letzte Posting mit MAX(posting_date) zu bekommen) in den Speicher und hole mir dann für _jeden einzelnen Thread_ die Postings noch mal sortiert - oder b) ich hole mir wieder die Threadliste und dann _alle_ Postings auf einmal und sortiere sie dann im Speicher neu. Beide Möglichkeiten gefallen mir ehrlich gesagt überhaupt nicht, denn sie kosten sehr viel Performance, vor allem bei vielen Threads und Postings.
Mein Datenmodell sieht im Moment (auszugsweise) so aus:
threads
-----------
threadid
title
origposter
starting_date
postings
-----------
postingid
title
poster
message
posting_date
threadid
Die Lösung meiner Probleme wäre ein kompletter Bruch mit "gutem" Datenbankdesign: ich werfe die Normalisierung einfach über den Haufen. Wenn ich zu jedem Thread speichere, wann und von wem das letzte Posting "gepostet" worden ist, dann kann die Anzahl der DB-Abfragen, die ich durchführen muss, gering halten. Ich würde damit sogar so weit kommen, dass jetzt pro Scriptaufruf nur noch ca. 8 DB-Abfragen durchgeführt werden müßten, was zwar IMHO immer noch sehr viel ist, aber deutlich besser als vorher.
Die Nachteile, die mir dabei in den Sinn kommen:
1. potentieller Verlust der Integrität der Daten
2. "unelegant"
3. redundante Speicherung von Informationen
Was meint ihr dazu? Oder anders: konnte ich mein Problem verdeutlichen? Habe ich etwas übersehen? Ist mein Datenmodell suboptimal?
Viele Grüße,
Christian
[1] Ich unterlasse jetzt einfach mal die Rechtfertigungen. ;-)
Hast Du einen Beitrag? Nur her damit!
http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm
SELF-Code: (http://emmanuel.dammerer.at/selfcode.html)
sh:) fo:) ch:] rl:( br:> n4:& ie:% mo:) va:) de:] zu:) fl:( js:| ss:) ls:[