nicht angemeldet
Moin!
(Ich könnte das natürlich auch in PHP machen, dort wird das Ergebnis weiter verarbeitet, aber ich meine, es ist performanter, soviel wie möglich direkt von SQL erledigen zu lassen.)
Den Performancevorteil würde ich doch in Frage stellen wollen.
Für 90% aller Seiten, die ein geringes bis kleines Besucheraufkommen haben und deshalb auf einer Maschine gehostet werden können, ist es sicherlich von der Performance her egal. Da gelten ganz andere Erfordernisse, nämlich vor allem, dass man einfach, effizient und schnell Code schreiben und warten kann. In solch einer Situation ist das Vorformatieren in SQL also kein Performancevorteil, sondern eine willkommene Vereinfachung des Codes.
Aber die Datenbank ist, wenn man weiter wächst, der letzte Teil, der immer noch "Single" bleibt. Erster Wachstumsschritt: Webserver und DB trennen. Zweiter Schritt: Mehr als ein Webserver, immer noch eine Datenbank.
In solch einer Situation ist die Datenbank dankbar für alles, was sie NICHT tun muss, und was man parallelisiert in die PHP-Skripte packen kann, die verteilt auf der erweiterbaren CPU-Power der Webserver laufen (dritter Webserver dazu ändert am grundsätzlichen Setup nichts).
Erst wenn der einzige DB-Server die Last nicht mehr schafft, wird es spannend - aber bis hierhin hat sich in der Struktur der programmierten Webanwendung im Prinzip noch nicht wirklich etwas geändert.
Solche Lastsituationen sind aber für die Mehrheit der Sites irrelevant, weil sie nie in solch einer Liga spielen.
Deshalb: Das Performanceargument ist an dieser Stelle eher falsch. Ein korrektes Argument wäre, sich in PHP nicht mit den Unzulänglichkeiten des DB-Schemas herumschlagen zu müssen, weshalb die Konvertierung schon im SQL gemacht wird. Das hat mit Performance nichts zu tun, aber mit vernünftiger Struktur und Aufteilung von "wer macht was".
- Sven Rautenberg