Stored Procedures

[Dirk Munzinger]

Moin,

> Ich habe gerade mal ein bi�chen im Archiv der allgemeinen
> Mailingliste herumgest�bert. Die Experten sind sich einig, da�
> stored procedures gut durch Middleware, also zum Beispiel php,
> aufgefangen werden kann. Einige bezweifeln sogar den Wert von
> stored procedures und halten es f�r viel sinnvoller die
> entsprechenden Aufgabe mit Middleware zu l�sen.

Das Problem, dass ich immer wieder bei Stored Procedures sehe ist, dass
diese datenbank/herstellerbezogen sind, die verwendete Sprache meist
keiner "Norm" entspricht und die Sprache selbst sehr limitiert ist;
ferner kommt noch hinzu, dass diese sich sehr schlecht debuggen lassen
und man noch eine weitere Sprache lernen muss.
Das Problem bei PHP, Shell-Scripten oder sonstigen dieser Art ist, dass
das jeweilige Script �ber eine "externe Steuerung" aufgerufen werden
muss (z.B. crond) damit es seine Arbeit tut - dies kann u.U. zu einem
nicht akzeptablen Zeitdelta f�hren bzw. eine sofortiger Feedback an den
Client ist nicht gegeben - z.B. bei Fehlern in der Ausf�hrung der
Scripte.
Der Ansatz, der von Dana ...? implementiert wurde (siehe
MySQL-Entwickler-Liste) geht wohl in Richtung Script-Exit/Gateway -
soweit ich dies "aus der Ferne beurteilen kann", da ich es noch nicht
selbst getestet habe. Der Nachteil ist wohl hierbei, dass bei der
Ausf�hrung eines (perl)-Scriptes der Perl-Interpreter erst gestartet
werden muss, was auf die Performance dr�ckt. Ferner kommt noch hinzu,
dass die Scripte nicht im Namespace des MySQL-Servers selbst laufen,
also ein Reconnect auf den Server/DB notwendig ist, was zu einer h�heren
Last f�hrt.
Was mir gut an dem Konzept gef�llt ist, dass die Verwaltung der Scripte
in der DB selbst erfolgt (bitte korrigiert mich jetzt, wenn ich da etwas
falsch sehe).
Mein Ansatz mit "Dexter" (http://dlabs.4t2.com) geht in die Richtung,
dass ich einen Server zwischen den eigentlichen MySQL-Server und die
Clients schalte und den Datenstrom auswerte. Mittels bestimmter Befehle
kann dann die Scriptausf�hrung angesteuert werden. Auch hier ist aber
wieder der Nachteil, dass pro Verbindung eine zus�tzliche Verbindung zum
Server aufgebaut werden muss und die Scripte nicht im Namespace des
MySQL-Servers laufen.
Der Vorteil bei beiden Methoden ist, dass durch die Verwendung von Perl
oder anderer, bestehender Sprache nahezu alles m�glich ist, was diese
Sprachen so hergeben z.B. �ndern der Daten und gleichzeitiges l�schen
der Festplatte.
Mit den beiden Ans�tzen l�sst sich zwar eine Art Stored Procedure
Funktionalit�t nachbilden, aber bei Triggern scheitert es dann wieder
und diese sind je nach Anwendungszweck sehr n�tzlich.

Was ggf. auch schon eine Erleichterung darstellen k�nnte, w�re die
M�glichkeit Schleifen direkt in MySQL zu "programmieren", die z.B. auf
den internen Variablen aufbauen. Beispiel:

        while _(at)_a > 1000 do
                select _(at)_a := Feldwert1,
                       _(at)_b := Feldwert2
                from tab where ....
                update tab set Feldwert3 = 'Hallo' where id = _(at)_b
        .....
  

Was nat�rlich noch ganz oben auf meiner Wunschliste steht, sind
Sub-Selects und Views. Soweit ich noch richtig weiss sollen Sub-Selects
in der 4.1er von MySQL kommen aber Views wohl noch etwas dauern.

Gru�, Dirk

---
!!NEU!!
Fragen und Antworten zu MySQL und dieser Liste unter
-->>  http://www.4t2.com/mysql