Oracle2MySQL

[Ralf Narozny]

Dirk Munzinger wrote:

> Hi !
>
> Ralf Narozny wrote:
>
>>
>>
>> Das Problem, das ich damit habe, ist, daß viele Anwendungen gerade 
>> bei nicht-trivialen Anwendungen eine Menge Abhängigkeiten der Daten 
>> prüfen müssen. Das bedeutet, daß man Unmengen von Daten durch das 
>> Netz schieben muß. Dabei verliert man sehr viel Zeit und müllt das 
>> Netz voll (selbst wenn es sich nur um ein lokales Netzwerk handelt).
>
>
> Was spricht denn dagegen, die Mittelschicht auf dem gleichen Server zu 
> halten, wie die DB selbst ? Dann gibt es dieses Problem nicht - zumal 
> ich das auch nicht als ein Problem ansehe bei den Netzen heutzutage 
> und den Routingmöglichkeiten.
> Ferne geht es ja auch nicht um eine Desktop-DB like M$ A***


Dagegen spricht, daß nicht immer die Datenbank nur idled. D.h. ich habe 
Datenbanken gesehen (Oracle), die am Rande des Wahnsinns agierten, ohne 
daß irgendwelche anderen Prozesse auf der DB-Maschine liefen. Außerdem 
bedeutet die Tatsache, daß ich beim Hin-und-Her-Schaufeln auch noch 
immer Netzwerkdelay habe, d.h. Ich werte das erste Token aus, stelle 
dann die Anfrage für das zweite, warte auf Antwort,... sicher kann man, 
wenn die Statements einfach sind, mit einem auskommen, aber das geht 
auch nicht immer. Dann erzeugt man immer mehr Wartezeit, die ein 
Netzwerk verursacht...Klar ist, daß das bei Zwergenanwendungen mit 1.3 
concurrent Usern kaum merklich ist, wie aber mit 5000...?

>
>> Stored Proedures sind in vielen Belangen einfach praktisch:
>> - Sie sind im Normalfalle bereits kompiliert (Query plans müssen 
>> nicht/seltener erstellt werden -> Zeitgewinn, Einsparung von 
>> Rechenzeit, die sonst die Applikationserver leisten müssten)
>
>
> Die Faulheit siegt ;-)


Wo Faulheit? Ein Query-Plan wird vom Query-Optimizer einer DB erstellt, 
nicht von einem Menschen ;-)

>
> Diese Aussage kann ich nicht bestätigen; sprich ich hatte bisjetzt mit 
> Laufzeiten etc. keinerlei Probleme. Entkopplung von Prozessen.


Aha, also Du hast noch keine Probleme gehabt ;-) Ich schon ;-)

>
>> - Kaskaden von Abfragen lassen sich ohne großen Zeitverlust erledigen 
>> (ohne das dauernde Hin-und-Her bei Übertragungen API->DB->API->...)
>
>
> Was meinst Du damit ? Ich kann mir doch "höhere" Funktionen 
> zusammenstellen, die die Arbeit für mich erledigen - muss ich auch, 
> damit ich entsprechen neutral arbeiten kann. Beispiel hierfür Perl's DBI.


Ich habe irgend ein Token, damit starte ich die Anfrage, das weitere 
Vorgehen ist dann jeweils abhängig vom letzten Zwischenergebnis:

(billiges Beispiel (NICHT realistisch): User hat ID 25, dann finde ich 
raus, daß seine Daten in Tabelle XY25 liegen, worin wiederum steht, daß 
sein Konto in Tabelle BLAH16 geführt ist, dann mußt Du zuerst die 
Abfrage stellen, wo die Daten über die Kontotabelle liegen, die Antwort 
abwarten, danach mußst Du XY25 abfragen und erst mit dem Ergebnis 
bekommst Du, wo Dein endgültiges Resultat steht)

Das bedeutet Du hast immer Wartezeiten und Netzwerkdelay, den Dir eine 
Stored Procedure erspart.

>
>
>> - Transaktionen können gekapselt werden, ohne das Fehler bei 
>> Netzwerkübertragungen oder Stolperern in der API durchschlagen (die 
>> Transaktionssteuerung einer DB zu überlassen erspart sicher einige 
>> tausend Stunden Konzeptionierung und Implementierung)...
>
>
> Transaktionen gehören in die DB. Das habe ich auch nicht bestritten 
> sondern eher noch betont. Das sehe ich auch als die grundlegende 
> Aufgabe des RDBMS.
>
>> Insgesamt, ist die Idee DB-unabhängig zu coden toll, aber leider 
>> realitätsferner als man denken mag....
>
>
> Immer diese negativen Stimmungen ;-) und so realitätsfremd ist es nun 
> auch wieder nicht, schliesslich gibt es auch einige (kommerzielle) 
> Produkte auf dem Markt die mit verschiedenen DBs können und ich denke 
> nicht, dass die Entwickler für jede unterstütze DB die Sache neu 
> implementieren - hängt halt in erster Linie von dem Gesamtdesign ab.


Ich habe nicht gesagt, daß er völlig realitätsfern ist, sondern daß es 
nicht so perfekt ist, wie es klingt... ;-)

>
>

Gruß
 Ralf

-- 
Ralf Narozny
SPLENDID Internet GmbH & Co KG
Skandinaviendamm 212, 24109 Kiel, Germany
fon: +49 431 660 97 0, fax: +49 431 660 97 20
mailto:rnarozny_(at)_splendid.de, http://www.splendid.de



---
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql