Kategorie-Archive: Programmiersprachen

10 falsche Vorstellungen über PHP

Ich mag PHP. Habe es schon immer gemocht, seit ich in meiner Schulzeit von HTML(3)-Markup – was ich davor für Programmieren hielt – zu echten Programmiersprachen gewechselt bin. PHP ist einfach zu erlernen, bietet viel Komfort und, unter Beachtung verschiedener Voraussetzungen, eine hohe Performance bei Nutzung relativ weniger Systemressourcen. Zudem ist es (fast) überall im Web verfügbar, egal ob beim Free-Hoster mit Werbefinanzierung oder auf dem 800-Euro-pro-Monat-Rootserver.

Hartnäckig halten sich allerdings zahlreiche Gerüchte über PHP, von schlechter Performace (sehr häufig) über Bedenken wegen fehlender Objektorientierung bis zur Angst, dass Zend aufgrund seiner Vormachtstellung im Development von PHP die Sprache vollständig kontrolliert. Manuel Lemos hat dazu auf phpclasses.org einen sehr guten Artikel verfasst, den sich jeder Interessierte mal zu Gemüte führen sollte. Sogar als erfahrener Developer kann man dort noch das ein oder andere, das man vielleicht noch nicht wusste, erfahren. Oder wussten Sie, dass man mit PHP Windows-Dienste erstellen kann?

MySQL und Index – oder: warum %-Zeichen böse sind

Heute bin ich auf eine interessante Sache gestoßen, die eigentlich ganz logisch ist (wenn man ein wenig über Bäume Bescheid weiß), auf die man aber von allein trotzdem erst nach viel Nachdenken kommt wie ich finde. Daher will ich sie niemandem vorenthalten :)

Es fing alles damit an, dass MySQL-Queries des XMLArsenal (siehe Projekte) unglaublich lange brauchten. Ein JOIN über 3 Tabellen mit WHERE-Clause auf einer und Primärschlüsseln in allen Tabellen (die zum JOIN verwendet wurden) brauchte teilweise bis zu 2 Sekunden. Nun ist der Datenbestand recht groß, etwa 170.000 Zeilen (~2GByte) in der größten Tabelle. Trotzdem konnte es eigentlich nicht angehen zumal auf der Namensspalte, die ich in der WHERE-Clause verwende, bereits ein Index definiert war. An dieser Stelle muss ich mich bei Silvan Mühlemann von techblog.tilllate.com bedanken, sein Artikel “Optimierung von MySQL-Abfragen: Verwendung des Index” hat mich auf die richtige Spur bzw. eigentlich gleich zur richtigen Lösung gebracht: Nutzt man

1
LIKE %Name%

kann MySQL den definierten Index nicht nutzen, d.h. wieder Scan über die ganze Tabelle. Lässt man das vordere % weg wird das Ergebis zwar kleiner aber es steht der Nutzung des Index nichts mehr im Wege – Speedup in diesem Fall: 50.000-fach. Merke: kein % vorn wo es nicht unbedingt nötig ist. Faszinierend. :)

Flash “drängelt sich vor”

Beim Erstellen von Websites, die Flash beinhalten, ist mir schon des öfteren eine kuriose Eigenschaft des Flash-Objekts aufgefallen: Es ignoriert die natürliche Reihenfolge der Elemente (z-Index) und wird grundsätzlich als oberster Layer angezeigt. Damit überdeckt es ggf. auch absolut positionierte Elemente, bei denen einen z-Index definiert ist. Dieses Verhalten wird von Adobe sogar in einem extra Knowledgebase-Artikel beschrieben (warum auch immer es nicht einfach gleich dem Standard angepasst wird): tn_15523.

Um dieses Verhalten zu umgehen muss man nur einen zusätzlichen Parameter

1
<param name="wmode" value="opaque" />

einfügen, gültige Werte für value sind dabei window (default), opaque, und transparent. Bei den letztgenannten tritt dabei die Missachtung der z-Reihenfolge nicht auf.

mod_rewrite für ein “MVC”-ähnliches Verhalten

mod_rewrite sollte jedem, der schon etwas Erfahrung im Bereich Webprogrammierung hat, ein Begriff sein. Es wird häuftig verwendet, um “SEO-friendly” – also suchmaschienenoptimierte – URLs für dynamische Websites zu erzeugen. Auch das MVC-Modell sollte als geläufiges Entwurfsmuster bekannt sein. Nun braucht man aber nicht bei jedem Projekt MVC, denn kleine Projekte werden dadurch schnell sperrig; oft reicht auch einfach ein Umschreiben auf bestimmte URLs und die Verwendung einer Template-Engine. Leider konnte ich nirgends im Web ein Beispiel finden wie man jetzt genau http://domain.com/user/add in http://domain.com/user.php?action=add umschreibt.

Daher nun hier mein Bespiel einer .htaccess, die genau das ermöglicht:

1
2
3
4
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule   ^([^/]+)/?([^/]*)/?    /$1.php?action=$2

Die RewriteCond verhindert hier, dass Dateien, die wirklich über diese URL erreichbar sind, ebenfalls umgeschrieben werden (wäre schlecht für Bilder, CSS usw.). Wenn man das Muster ([^/]*)/? wiederholt anhängt kann das genutzt werden, um noch tiefere Pfade in weitere Parameter umzusetzen, z.B. würde

1
2
3
4
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule   ^([^/]+)/?([^/]*)/?([^/]*)/?    /$1.php?action=$2&param=$3

dafür sorgen, dass man auch http://domain.com/user/view/45 in http://domain.com/user.php?action=view&param=45 umsetzen kann. So sind beliebige Pfadtiefen nutzbar.

Zu beachten ist, dass man im verarbeitenden Script die Parameter in $_GET nicht auf Existenz sondern mit Hilfe der Funktion empty() testen sollte, da automatisch leere Strings als Parameter übergeben werden falls der Pfad nicht die maximale Tiefe erreicht.