Fat Server oder lieber austauschbare Datenbank?

[Elvis]

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