Re: Stored Procedure - oder nicht.

[Dirk Munzinger <d_munzinger_(at)_sem-gmbh.com>]

Moin,

> > bekanntlich stehen einem unter MySQL keine Stored Procedures zur
> > Verfügung und auch die ToDo-Liste lässt nicht darauf hoffen, dass dies
> > in Kürze implementiert wird.
> >
> 
> IMHO macht es auch keinen Sinn mehr, mit dieser Technik weiter zu
> arbeiten. PERL mit seinem DBI Interface ist so unglaublich leistungsfähig
> und universell, daß man auf proprietäre Lösungen von Datenbankherstellern
> verzichten kann.

Dieser Meinung schliesse ich mich an. Die Möglichkeiten mit Perl sind
wirklich sehr gut.


> > Leider habe ich aber immer wieder Fälle, wo es sinnvoll wäre, auf SPs
> > zurückgreifen zu können; insbesondere in C/S Bereich muss diese ganze
> > Funkionalität im Client untergebracht werden, was zur Folge hat, dass
> > bei Änderungen der Client neu erzeugt und verteilt werden muss - unter
> > Windows eine sehr angenehme Arbeitsweise...
> >
> > Mich würde mal interessiere, auf welche Art und Weise andere Leute
> > dieses Problem umgehen oder auch nicht umgehen z.B. mittels eines
> > Script-Servers ? Insbesondere im Umfeld MySQL unter Linux und die
> > Client-Anwendung unter Windows.

> Ich mache alles mit PERL und dem DBI Interface. Unter Windows ist ACTIVE
> STATE PERL zu empfehlen.
> Für PHP gibt es inzwischen auch eine DBI Klasse. Wer also BASIC als die
> angenehmere Programmiersprache empfindet, der ist bei PHP mit DBI besser
> aufgehoben.

Active State Perl habe ich zwar vor kurzem bei mir installiert, aber
noch nichts damit gemacht. Stellt sich die Frage, ob man es direkt in
die Anwendung einbinden kann oder ob jedesmal das (lokale?) Perl-Script
aufgerufen werden muss. Aber wie bereits gesagt, stelle ich mir vor,
dass die Scripte auf dem DB-Server liegen und dort ausgeführt werden,
ansonsten hätte mensch wieder das Problem mit der Verteilung der
Scripte.

Gruß,
Dirk

---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe