Hi,
Du kannst gleiche Elemente gruppieren und ihre Summe/Durchschnitt berechnen. Aber letzten Endes sind das Zahlenoperationen. Für Texte ist in dem Modell erstmal kein Platz, damit schert GROUP_CONCAT aus der Reihe.
Aus Programmierersicht (im Gegensatz zur Mathematikersicht) ist eine Funktion, die Texte hintereinander setzt, erst mal auch nur eine Definition mit Code dahinter, wie eine Funktion, die Zahlen addiert. Ein Datenbankmodell hängt in dem Sinne da noch nicht dran, ob SUM() nun zusammenzählt oder hintereinander setzt. Also hätte (ich weiß, hätte...) man - wie mit GROUP_CONCAT geschehen - auch was im Standard drehen können.
Und was mehrere Abfragen angeht, es gibt kein Gesetz, dass eine Seite aus einer Abfrage zusammengestellt werden muss.
Ist aber aus Performance-Gründen wünschenswert. Eine Abfrage mit simplen JOINs, die vom DB-Server entsprechend optimiert werden können, wäre der Idealfall.
Überleg doch mal, wenn du dir das komponentenorientiert vorstellst, dann hast du eine Komponente, die sich mit der Ausgabe des Blogs befasst,
Ja. Daran arbeite ich im Prinzip.
und eine weitere, die sich mit der Ausgabe von Tagclouds befasst.
Daran auch, sobald geklärt ist, wie die Tags gespeichert werden.
Logischerweise hättest du dann zwei Abfragen und das wäre völlig in Ordnung.
Hier kommt z. B. die Auflistung mehrerer Blogeinträge auf einer Seite ins Spiel. Für jeden Eintrag (also beispielsweise 10 Einträge pro Seite) noch mal eine Abfrage für die Tags - das macht dann schon 1+10=11 Abfragen. Oder aber einen komplizierten Code, der die IDs der Blogeinträge in eine neue Abfrage wurschtelt, die durchführt, und dann aufpassen muss, dass diese auch wieder korrekt zugeordnet werden.
Klar wär es kein Problem, mehrere Abfragen zu machen - ich will aber das ganze recht performant halten, d. h. nicht wie diverse Boards, die auf massig Abfragen setzen (irgendwo hatte ich da mal in einem Blog was gelesen, da wurde so ein Teil regelrecht auseinander genommen wegen seinen 50 Abfragen pro Seitenabruf oder so)...
e7