Re: Möglichkeit für Stored Procedures

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

Moin,


> 
> Wer sich mit einer objektorientierten Programmiersprache auskennt, der wird sich
> in JAVA sehr schnell einarbeiten können.
> 
Da gebe ich Dir recht, Java ist nicht das Problem, aber mal auf die
Schnelle für ein kleines Script doch schon Overkill.

> >
> > Lieblings-Script/Programmiersprache) und ferner ist Java derzeit -
> > meines erachtens - ein erheblicher Resourcenfresser und stellt, für
> 
> Unter http://www.little-idiot.de/mysql/mysqllive.html ist eine JAVA
> Client/Server Applikation realisiert. Dahinter steckt (JAVA) SQL Server und JAVA
> Client. Die Daten selber liefert wiederum MySQL. Da JAVA ja clientseitig
> abläuft, ist das sogar recht schnell.
> Dieses ganze (Trainings) - Applet sind ca. 2 A4 Seiten Code, mehr nicht.

Hab's gesehen, aber 2 Seiten ich schon enorm :-)

> Nö, ich habe riesige Datenbanken auf meinem P233 128 MByte laufen, ca. 2.400.000
> Einträge -
> sauschnell (3-10 Queries/Sekunde).

Wer die Handhabung von Keys kennt war schon immer im Vorteil :-))) Diese
Werte kann ich eigentlich nur freudig bestätigen - auch unter
"schlechterer" Hardware.

> In letzter Zeit häufen sich die (performance-) Probleme bei Providern, die MySQL
> und PHP anbieten. Das ist ein völlig anderes Problem. MySQL mit SQLJ Client ist
> bei vielen Anwendungen viel schneller, als ORACLE o.ä. (Faktor 2-3). Ob JAVA nun
> langsam oder schnell ist, spielt nur bei serverbasierten Applets eine Rolle.
> Hier knicken auch meine SUN's völlig ein - Beispiel Enhydra Projekt. LINUX ist
> da noch katastrophaler, weil JAVA bisher (hopefully in 1.2 beseitigt) nur mit
> green threads arbeitet, also echte, multithreaded ,Applikationen nicht
> funkionieren.
> Z.B. Autoren-Systeme mit Shop, die auf JAVA basieren, wie z.B. OpenMarket, die
> sind erstens schweineteuer und brechen sehr schnell ein.

Noch ein Grund, derzeit von Java abstand zu halten. Auf der anderen
Seite, wenn man externe Scripte aufruft, die dann jedesmal noch einen
Connect abarbeiten kann das auch zu starken Performance-Einbrüchen
führen - man muss die Sache genau beobachten und wissen, was man tut. 

> Das ist korrekt. JDBC ist aber nicht so langsam, wie ODBC. Wer allerdings
> JDBC-ODBC Bridges einsetzt, der hat verloren. Die Performance ist saumäßig -
> warum ? Zuviel M$ Code drin ;-)

Ach, M$ hat schlechten Code :-))

Aber nochmals zum eigentlichen Thema zurück: 
mir scheint, als hätte bisher mit dem Vorschlag, externe Scripte von
MySQL aus aufzurufen noch niemand etwas zu tun gehabt oder gibt es sonst
noch Lösungsansätze ?
Dann muss ich mir die Sache doch mal genauer anschauen. 

Gruß,
Dirk

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