Oracle2MySQL

[Ralf Narozny]

Dirk Munzinger wrote:

> Moin,
>
> Rafal Kedziorski wrote:
>
>> Hallo,
>>
>> Geht aber, wenn man auf einige Sachen verzichten kann (z.B. 
>> Proceduren). Dann muss man das über Softwarelösungen abdecken. Ich 
>> will MySQL und PostgreSQL versuchen, da es eine kleine Variante von 
>> der Software geben soll, die auf OpenSource basiert. Das alles ist 
>> aber Zeitabhängig.
>>
>
> mal eine allgemeinere Anmerkung zu dem Thema Portierung und 
> DB/Softwaredesign:
> Man sollte sich grundsätzlich überlegen, wo man die Anwendungslogik - 
> gerne auch als Geschäftslogik bezeichnet - implementiert.
> Die Verwendung von Stored Procedures, Triggers und hersteller-SQL ist 
> IMHO ein Softwaredesign, dass man NICHT anstreben sollte, denn dann 
> ist man dem DB-Hersteller ausgeliefert - wie man auch in diesem Thread 
> sehen kann. Ferner sind die Möglichkeiten solcher SP-Sprachen recht 
> begrenzt.
> Für mich gilt grundsätzlich die DB als das anzusehen was sie ist: ein 
> Datenspeicher, der mir bitteschön die Daten sauber und stabil vorhält 
> - nicht mehr und nicht weniger - und kein Anwendungsserver oder was 
> weis ich alles noch.
> Von daher müsste in einem sauberen Softwaredesign alles was nicht mit 
> Daten sondern mit Logik zu tun hat in eine Zwischenschicht gepackt 
> werden (Stichwort: Appserver, n-tiere etc) und darauf geachtet werden, 
> dass die Abfragen bzw. Datenmanipulationen sich auch nach dem 
> SQL-Standard richten (was allerdings auch nicht immer möglich ist wie 
> z.B. Autoincrement bei MySQL wird bei anderen RDBMS mittels Generator 
> erreicht). Somit kann der Portierungsaufwand stark reduziert und eine 
> höhere Produktunabhängigkeit gewährleistet werden. Besonders auf 
> Letzter würde ich in dem schnelllebigen Softwarebereich besonders achten.


Ja und nein!

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

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)
- Kaskaden von Abfragen lassen sich ohne großen Zeitverlust erledigen 
(ohne das dauernde Hin-und-Her bei Übertragungen API->DB->API->...)
- 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)...

Insgesamt, ist die Idee DB-unabhängig zu coden toll, aber leider 
realitätsferner als man denken mag....


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