Oracle2MySQL

[Dirk Munzinger]

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***

> 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 ;-)
Diese Aussage kann ich nicht bestätigen; sprich ich hatte bisjetzt mit 
Laufzeiten etc. keinerlei Probleme. Entkopplung von Prozessen.

> - 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.

> - 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.


Gruß, Dirk


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