Konzept: PHP-include oder mySQL stored procedures?

[Rolf B]

Hallo Linuchs,

deine Frage ähnelt der nach dem Unterschied zwischen konkav und konkret.

Ajax, PHP include und Stored Procedures sind Themen, die ziemlich disjunkt sind.

Was Ajax ist, muss ich Dir nicht erklären. Aber mit Ajax lagerst Du aus deinem PHP Code keine DB Zugriffe aus.

Mit PHP include kannst Du wiederholten Code in Dateien sammeln. Aber das allein ist nicht die Lösung. Ein include wird von PHP so behandelt, als stünde das includete PHP File an der Stelle, wo der inclue-Befehl steht. Es gibt keine Parameter. Es gibt keinen sinnvollen Return-Wert. Eine Sammlung von Codefragmenten, die mit include geholt werden, verschärft das Spaghetti.

Wie fit bist Du mit selbstgemachten Klassen? Aus meiner Sicht sinnvoll sind sogenannte Repository-Klassen, die Zugriffe auf bestimmte Inhaltsdomänen bündeln. Das können die allgemeinen CRUD^[1]-Zugriffe sein, aber eben auch Spezialzugriffe. Wichtig ist hier, die Zugriffe nicht zu spezifisch zu machen. Beim Bau eines Repository kann man sich viel Arbeit machen, die muss dann gut überlegt sein, oder man sammelt dort einfach alle Zugriffe für einen bestimmten Inhalt als Methoden. Ohne OOP muss man viele Funktionen bauen und mehr Parameter durchreichen.

Stored Procedures oder Stored Functions sind Logikblöcke, die nicht im PHP, sondern in SQL Server ausgeführt werden. Du kannst komplexere Abfragen in Stored Procedures bündeln, aber tauschst damit nur einen Schwarm Zeugs im PHP gegen einen Schwarm Zeugs im SQL Server. Performancevorteile gewinnst Du damit nicht. Stored Procedures haben zwei Anwendungsfälle:

(1) Security. Man kann Leuten Daten aus einer Table bereitstellen, ohne ihnen einen SELECT auf die Table oder einen View darauf zu GRANTen. Das ist für Dich uninteressant, weil Du ohnehin alle Zugriffe über eine technische User-ID machst.

(2) Chattyness reduzieren. Wenn PHP und SQL auf unterschiedlichen Blech laufen, ggf. sogar noch mit einer latenzreichen Strecke dazwischen, ist Programmcode, der viele SQL Abfragen absetzen muss um ein bestimmtes Ergebnis zusammenzubauen, ineffizient. Je langsamer oder latenzreicher die Verbindung zwischen zwei Komponenten ist, desto eher gilt der Grundsatz: be chunky, not chatty. D.h. eine Query mit einem großen Ergebnis ist vielen kleinen Queries vorzuziehen. Wenn PHP und SQL auf dem gleichen Prozessor laufen, ist ggf. immer noch ein Unterschied da, aber er ist gering.

Stored Procedures haben vor allem einen großen Nachteil: sie debuggen sich schlecht. In PHP kannst Du Debugger einsetzen, oder Dir den Wolf loggen. Bei Stored Procedures ist das schwieriger. Es ist auch mühseliger, in einer Stored Procedure mit dynamischem SQL zu arbeiten (ein Statement mit String-Operationen zusammenzusetzen. GEHEN tut es, es gibt PREPARE stmt FROM string als SQL Befehl.

Stored Functions unterscheiden sich von Stored Procedures dadurch, dass sie einen Wert zurückgeben. Damit kannst Du sie in einem SQL Statement wie eine eingebaute Funktion verwenden. Die Stored Function kann selbst SQL durchführen, oder einfach nur Logik enthalten.

Also - was Dir helfen sollte, ist eine Code-Reorganisation, so dass Du mit möglichst wenig unterschiedlichen SQL Zugriffen auskommst. Das ist erstmal viel Arbeit für die Bestandsaufnahme, vor allem bei Verwendung von dynamischem SQL. Und dann sieh zu, dass Du die Zugriffe sortierst und kapselst. Überleg Dir auch bei Monster-SQLs, ob es die Mühe Wert ist, das in SQL zu tun, oder ob man es auch mit einfacheren SQL Bausteinen im PHP zusammensetzen kann.

Rolf

---

1. crud, engl. für Dreck oder Mist. CRUD - Akronym für Create Read Update Delete, also das Dreckszeug, das man immer wieder programmieren muss und wovon uns die ORM Frameworks erlösen wollen, um uns dafür crud auf anderem Level zu bescheren. ↩︎