Zitat von
Bernhard Geyer:
Zitat von
smudo:
Das kommt wohl darauf an, wie oft man seine
DB austauscht. Zeigt die Praxis nicht eher, dass dieser Fall sehr selten eintritt?
Als SW-Anbieter wenn man seine Anwendung nicht nur für
DBMS "A" sondern auch für
DBMS "B" anbieten will ist es u.U. sehr aufwendig für jede
DB die SP's zu programmieren.
Ganz genau.
Ußerdem ist selbst Oracles PL/
SQL noch abartig hässlich, verglichen mit den Hochsprachen, mit denen man in einem Applikationsserver die Businesslogik implementieren würde. Und verglichen mit PL/
SQL ist so ziemlich jeder andere prozedurale
SQL-Dialekt abartig hässlich...
Wenn das nicht in der
DB gemacht wird, wird diese auch noch entlastet. Skalieren durch das Aufrüsten der Applikationsserver oder das Hinzufügen von weiteren kostet nur Hardware. Beim Aufrüsten von
DB Servern fallen auch noch die recht
happigen Lizenzgebühren an. (Es gibt kaum clusterfähige, freie
DBMS')
Ein
DBMS, das nicht clusterfähig ist, als die einzige serverseitige Implementierung zu benutzen heißt, dass euer System
gar nicht skalieren kann.
Das ist ganz böse, denn solche System sind es die mit wachsenden Unternehmen irgendwann nicht mehr mithalten können. Ein verantwortungsvoller IT'ler würde sich also vehement gegen euer System aussprechen (und zu 100% recht haben!).
Falls ihr euch in beiden Lagern nur um eine klassische 1990'er, 2-schichtige Client/Server-Anwendung gezankt habt, solltet ihr dringend über eine mehrschichtige Lösung nachdenken, bei der der Client keine Businesslogik implementiert, die steckt im App-Server.
Außerdem ist die Datenbank nur innerhalb des Serverraums, nur für die App-Server sichtbar, was die ganze Sache viel sicherer macht. Außerdem könnt ihr so ein eigenes User-/Authentifizierungssystem benutzen, was mehr über einen User weiß als es ein
DBMS könnte.
Authentifizierung über LDAP oder Active Directory wäre dann auch möglich...