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