Fat Server oder lieber austauschbare Datenbank?

[squetk]

Hallo,

in unserem Programmierteam tobt ein Glaubenskrieg :twisted: - 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:

Zitat von squetk

(Vorteil u.a.: Performancegewinn

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

Zitat:

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:

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:

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:

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:

Zitat von smudo

Zitat:

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:

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:

Zitat von Bernhard Geyer

Zitat:

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:

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.

[shmia]

Wenn mehr als eine Datenbank unterstützt werden soll, dann ist man gezwungen die gemeinsame Schnittmenge des Funktionsumfangs zu verwenden.
Manchmal bedeutet dies, dass man keine Stored Procedures verwenden kann, obwohl SPs zusätzliche Geschwindigkeit und Sicherheit bringen würden.
Man sollte neben den SPs aber immer auch Views verwenden; diese sind bei fast jeder DB verfügbar.
Stellt sich nun die Frage, wieviele und welche Datenbanken unterstützt werden sollen.
Bei zwei oder drei verschiedenen Datenbanken ist es manchmal noch möglich, die SPs in allen Datenbanken zu verwenden.
Hat man allerdings die Vision alle gängigen DBs zu unterstützten, wird die gemeinsame Schnittmenge sehr klein und der Aufwand sehr gross.
==> um den Glaubenskrieg zu entscheiden, muss bekannt sein, welche Datenbanken unterstützt werden sollen.

[squetk]

Zitat:

um den Glaubenskrieg zu entscheiden, muss bekannt sein, welche Datenbanken unterstützt werden sollen

Es geht vorerst "nur" um FireBird und den MS SQL Server.

[Phoenix]

[quote="squetk"]

Zitat:

und den MS SQL Server.

2000? 2005? 2008? Allein schon zwischen 2000 und 2005 gibt es massige Unterschiede, die eine portabilität der SP's nicht immer gewährleistet.

[squetk]

@Elvis:

Zitat:

Falls ihr euch in beiden Lagern nur um eine klassische 1990'er, 2-schichtige Client/Server-Anwendung gezankt habt

Schöne Umschreibung - klingt wie ein guter Wein :-D
Sind Client/Server-Lösungen unmodern? Mehrschichtige Anwendungen haben unbestritten ihre Vorteile - sind aber auch aufwändiger zu entwickeln.

@Phoenix:
Alle Versionen ab 2005. Aber wenn das stimmen sollte, dass die SP's u.U. nicht kompatibel sind, wäre das ein harter Schlag für die Fat-Server-Fraktion (Aussage: "...wer erstmal den SQL Server einsetzt, wechselt auf keine andere Datenbank mehr...") :-D

[mkinzler]

Es wird dir keiner heute sagen können, wie zukünftige Versionen aussehen, bzw. eine Garantie geben, dass deine SPs auf zukünftigen Versionen der Datenbanken gehen.

[Phoenix]

Zitat:

Zitat von squetk

@Phoenix:
Alle Versionen ab 2005. Aber wenn das stimmen sollte, dass die SP's u.U. nicht kompatibel sind, wäre das ein harter Schlag für die Fat-Server-Fraktion (Aussage: "...wer erstmal den SQL Server einsetzt, wechselt auf keine andere Datenbank mehr...") :-D

Naja, die Unterschiede die hier aufgeschlagen sind betrafen 2000 <> 2005. Ich hab die noch nicht auf der aktuellen 2008er Beta getestet... Aber selbst wenn dürfte ich nicht drüber schreiben *g*

Und die Aussage ist so schlichtweg falsch. Der SQL Server ist die einzige Datenbank, die sich nicht auf Linux-System einsetzen lässt. Ein absolutes K.O.-Kriterium für viele Rechenzentren in Firmen. Von allen anderen Datenbanken gibt es Linux-Versionen. Also eher noch ein Grund, auch andere Datenbanken zu unterstützen.