So, nach längerer Zeit melde ich mich zurück.
Leider muss ich sagen, dass mir öfters die Lust zum Bloggen fehlt - vielleicht weil ich lieber lebe anstatt über mein Leben zu schreiben. Der klassische Tagebuch-Schreiber bin ich ohnehin nicht, also werde ich in Zukunft ab und zu über meine Arbeit bzw. Dinge, die mir in diesem Zusammenhang auffallen, schreiben.

Zum Beispiel über MySQL. Das ist ein Datenbank-Management-System. So wie Oracle. Oder M$-SQL. Nur schlechter.
Oh ja, ich höre den Aufschrei vieler Webentwickler, die nach meiner Steinigung verlangen, doch ich kann nach dem gestrigen Tag leider nichts anderes sagen.

Für verschiedene Projekte ist es notwendig, dass ich z.B. einem Workflow-Entwickler einfache Schnittstellen an die Hand geben, über die er Dinge aus Datenbanken abfragen kann. Je nach dem, wie komplex eine Datenbank aufgebaut ist, kann die Abfrage nach einer bestimmten Information sehr kompliziert sein.
Für diesen Fall gibt es in allen professionellen Datenbank-Management-Systemen die Stored Procedures (oder Stored Functions), in der Datenbank gespeicherte Programme, die in der Lage dazu sind, verschiedenste Aktionen auszuführen und z.B. eine Tabelle mit Informationen zurückzugeben. Außer bei MySQL.

Natürlich, MySQL bietet ebenfalls Stored Procedures an. Leider haben diese den Nachteil, dass sie keine Tabellen mit Informationen zurückgeben können. Die Stored Functions aus MySQL können nur einfache Datentypen zurückgeben, die Stored Procedures geben sämtliche Abfragen nicht an den Caller sondern an den Client zurück - was viele Systeme nicht verarbeiten können.
Nun ist mir allerdings auch klar, warum in Webprojekten mit MySQL sämtlicher SQL-Code innerhalb der Server-Sprache (z.B. PHP) implementiert wird - eine meiner Meinung nach sowohl unsaubere als auch unsicherere Art der Programmierung (Natürlich kann man auch unsichere Stored Procedures schreiben, in der Regel weiß ein Datenbankentwickler aber, was er tun oder nicht tun sollte).

Ein ganz kleines Beispiel, um zu verdeutlichen, was die Verwendung von Stored Procedures für einen Unterschied macht:
Ohne den Einsatz von Stored Procedures, muss mein Kollege von der Workflow-Entwicklung z.B. so etwas in seinen Workflow implementieren:

SELECT author.ID, CONCAT(author.PRENAME, CONCAT(' ', author.NAME)) AS NAME, book.ID, book.TITLE, book.DESCRIPTION, book.ISBN FROM AUTHORS author INNER JOIN BOOKS book ON book.AUTHOR_ID = author.ID WHERE book.TITLE LIKE '%Herr der Ringe%';

Mit Stored Procedures könnte das Ganze so aussehen:

CALL get_book_info( 'Herr der Ringe' );

Und das ist ein ganz einfaches Beispiel. Zusätzlich hat er nicht die Möglichkeit, die Abfrage mit Aktionen wie z.B. einem Log-Eintrag zu koppeln.

Mit dieser Beschränkung ist MySQL für mich ein ganz großes Stück zurück Richtung “Hobby-Frickel-Datenbank-Management-System” gefallen. Schade eigentlich.

MySQL | RSS 2.0 | Kommentar schreiben | Trackback