nicht angemeldet
(MySQL) Vereinfachung dieses SQL-Konstrukts?
Hallo,
ich hab folgende Situation: In einer Spalte (object_key) habe ich einen String, der z. B. so aussieht:
MMKK08-AB-ABCDEFG
Ich benötige nur den ersten Teil, vor dem ersten Strich. Nach durchforsten der MySQL-Doku habe ich nur SUBSTRING_INDEX gefunden, damit konnte ich das Problem so lösen:
SELECT SUBSTRING_INDEX( SUBSTRING_INDEX(oc.object_key, "-", 2), "-", 1) as brochure_code
Gibt es etwas einfacheres, als zweimal SUBSTRING_INDEX?
(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.)
Beste Grüße
Lars
-
Hi!
Ich benötige nur den ersten Teil, vor dem ersten Strich.
SELECT SUBSTRING_INDEX( SUBSTRING_INDEX(oc.object_key, "-", 2), "-", 1) as brochure_code
Gibt es etwas einfacheres, als zweimal SUBSTRING_INDEX?Einmal SUBSTRING_INDEX(). Warum schneidest du zuerst vor dem zweiten und dann nochmal vor dem ersten '-' ab und nicht gleich vor dem ersten ab?
Lo!
-
Hallo,
Einmal SUBSTRING_INDEX(). Warum schneidest du zuerst vor dem zweiten und dann nochmal vor dem ersten '-' ab und nicht gleich vor dem ersten ab?
lol! Keine Ahnung, das ist mir gar nicht aufgefallen. :) Danke!
Grüße
Lars
-
-
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
-
Hi!
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.
Warum nimmst du nicht gleich die DBMS-Replikation mit ins Spiel? Und warum stellst du diese Reihenfolge quasi als gesetzmäßig dar? Wäre es nicht sinnvoll, zunächst zu messen, wo der Flaschenhals ist und sich erst danach Gedanken um die Reihenfolge der Erweiterung zu machen? Oder ist es deine Erfahrung, dass immer zuerst der Webserver überlastet ist?
Lo!
-