Fat Server oder lieber austauschbare Datenbank?

[squetk]

Hallo,

in unserem Programmierteam tobt ein Glaubenskrieg - prinzipiell geht es darum, wieviel Funktionalität in den Datenbankserver ausgelagert werden sollte.

Es gibt einerseits die Meinung, dass die komplette Businessschicht in der Datenbank als Stored Procedures implementiert sein sollte (Vorteil u.a.: Performancegewinn und Funktionalitätsbereitstellung für unterschiedliche auf die DB zugreifende Clients).

Im Gegensatz dazu steht die Vorstellung, dass die Datenbank nur die Rolle eines reinen Datenspeichers spielt. Der Zugriff aus dem Programm erfolgt über eine möglichst universelle Datenzugriffsschicht, so dass das Datenbanksystem selbst austauschbar bleibt.

Da sich diese Konzepte grundsätzlich beissen, würde uns eure Meinung dazu interessieren!

[Phoenix]

Zitat von squetk:

(Vorteil u.a.: Performancegewinn

Das würde ich nicht unterschreiben. SP's sind zum Teil abartig Lahm.

Zitat von squetk:

Im Gegensatz dazu steht die Vorstellung, dass die Datenbank nur die Rolle eines reinen Datenspeichers spielt. Der Zugriff aus dem Programm erfolgt über eine möglichst universelle Datenzugriffsschicht, so dass das Datenbanksystem selbst austauschbar bleibt.

Allein der letzte Grund (Austauschbarkeit der DB) sollte ausreichend sein um sich dafür zu entscheiden.

[smudo]

Zitat von Phoenix:

Das würde ich nicht unterschreiben. SP's sind zum Teil abartig Lahm.

Laut meiner Erfahrung muss ich dem widersprechen. "abartig Lahm" ist auch schlecht messbar - auf welchen Ergebnissen beruht denn deine These?

Zitat von Phoenix:

Allein der letzte Grund (Austauschbarkeit der DB) sollte ausreichend sein um sich dafür zu entscheiden.

Das kommt wohl darauf an, wie oft man seine DB austauscht. Zeigt die Praxis nicht eher, dass dieser Fall sehr selten eintritt?

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

[Phoenix]

Zitat von smudo:

Zitat von Phoenix:

Das würde ich nicht unterschreiben. SP's sind zum Teil abartig Lahm.

Laut meiner Erfahrung muss ich dem widersprechen. "abartig Lahm" ist auch schlecht messbar - auf welchen Ergebnissen beruht denn deine These?

Sagen wir es mal so: Mit SP's haben wir die Zeitvorgaben des übergeordneten Systems bei einer Anlagensteuerung nicht erreichen können. Die gleichen Statements aus einer Anwendung abgesetzt haben die Zeitvorgaben erfüllt. Das ganze auf Oracle 10.

Und was die Portabilität angeht:
Du enwickelst für z.B. explizit für Oracle. Ein Kunde kommt zu Dir: 'Also wir würden hundert Lizenzen nehmen. Bei uns wird nur Firebird eingesetzt. Unterstützen Sie das?'. Der nächste Kunde kommt mit einer Konzernvorgabe: Nur SQL Server...

[squetk]

Ein Argument der Pro-Fat-Server-Fraktion lautet, dass eine universelle Datenzugriffschicht aufwändiger zu programmieren ist und nicht die jeweiligen Features der eingesetzten Datenbank berücksichtigen kann.

[Dax]

Zitat von squetk:

Ein Argument der Pro-Fat-Server-Fraktion lautet, dass eine universelle Datenzugriffschicht aufwändiger zu programmieren ist und nicht die jeweiligen Features der eingesetzten Datenbank berücksichtigen kann.

Das Argument kannst du mit Frameworks wie NHibernate nicht nur in den Wind schlagen, sondern deinen Gegnern auch gleich das nächste Argument versauern: mit Hibernate auf die Datenbank zuzugreifen ist weit weniger Fehleranfällig als über SQL und SPs.

[Phoenix]

Eine universelle Datenzugriffsschicht gibt es schon. Die nennt sich DBx4 und ist im aktuellen Delphi dabei. Muss man nicht aufwändig programmieren.

Natürlich kann man damit irgendwelchen speziellen xy-Features einer speziellen Datenbank nicht nutzen. Und das ist gut so. Denn dieses Feature xy, welches es nur auf dieser Datenbank gibt, könnte letzlich dafür sorgen, dass man einen risiegen Auftrag nicht bekommt. Eben weil man die Anwendung nicht auf die einzige Datenbank protieren kann, die der Interessent eben z.B. durch Konzernvorgaben einsetzen muss.

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

[Bernhard Geyer]

Zitat von Phoenix:

Eine universelle Datenzugriffsschicht gibt es schon. Die nennt sich DBx4 und ist im aktuellen Delphi dabei. Muss man nicht aufwändig programmieren.

Jein. Damit werden aber nicht (wie bei NHypernate oder ECO) auch die SQL-Unterschiede gekapselt.