Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm

[Frickler]

Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren und ansonsten alle Zugriffe programmgesteuert vornehmen:
- Daten in Listen/Objekte einlesen
- Daten in/mit diesen Objekten bearbeiten
- geänderte/neue Daten aus den Objekten wieder in der DB speichern
- direkte DB-Zugriffe (z.B. über datensensitive Steuerelemente) sind verboten
d.h. die ganze Datenbank in unteren Schichten verstecken und nur mit Objekten arbeiten. Die Datenbank ist nur Mittel zum Zweck, um Objekte zu persistieren. Damit wäre die verwendete Datenbank auch relativ egal, weil man eh mit dem kleinstmöglichen SQL-Subset arbeitet. Puristen verzichten sogar auf JOINs und machen auch das in der Anwendung.
Das wäre dann das Prinzip der dummen Datenbank mit dem schlauen Programm.

In manchen Datenbankbüchern wiederum wird gern das umgekehrte Prinzip beschrieben: fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern. Man ist dann natürlich abhängig von der verwendeten Datenbank. Auf Anwendungsseite ist der Zugriff flexibel, es könnten sogar datensensitive Steuerelemente herhalten, denn die Views und Trigger abstrahieren die normalisierte Tabellenstruktur einfach weg. Zudem kann ein passendes Rechtekonzept den Zugriff "am View vorbei" verbieten, so dass sämtliche Anwendungsprogramme die gleichen Zugriffe bekommen.
Das wäre dann die schlaue Datenbank mit dem dummen Programm.

In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.

Wie ist das bei euch so?

[Lemmy]

Servus,

Variante 2 - Leider. Denn StoredProcedures, Views und co. lassen sich ziemlich schlecht in Unit-Tests überprüfen. Code in Objekten dagegen sehr gut. Daher bauen wir auch gerade dahingehend um...

[Uwe Raabe]

Zitat:

Zitat von Lemmy (Beitrag 1361688)

Denn StoredProcedures, Views und co. lassen sich ziemlich schlecht in Unit-Tests überprüfen. Code in Objekten dagegen sehr gut.

Dazu kommt noch, daß damit ja ein Teil der Sourcen in der Datenbank des Kunden vor Ort abgelegt wird. Das ist bei Updates auch ein nicht zu unterschätzender Aufwand. Immerhin kann der Kunde ja auch mal eben eine alte Datensicherung wieder einspielen - mit den dann veralteten Stored Procedures.

[jobo]

Wir machen beides.

Ich persönlich mag schlaue Datenbanken. Es gibt sicher einen Haufen Argumente dafür und dagegen. Ich nenne zunächst mal 2 pro DB
+ heterogene Anwendungslandschaft spricht stark für eine DB, die schlau ist und "der Chef"
+ komplexe (viele Abhängigkeiten) und große Systeme haben m.E. einen Performancevorteil, wenn ein direkter Zugriff erfolgt.

[jobo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361690)

Immerhin kann der Kunde ja auch mal eben eine alte Datensicherung wieder einspielen - mit den dann veralteten Stored Procedures.

Das ist doch mit dem Datenmodell nicht anders, es kann auch veraltet eingespielt werden.

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361690)

Das ist bei Updates auch ein nicht zu unterschätzender Aufwand

Und bei einem Wechsel des DBMS der absolute Horror :twisted:

[grl]

Zitat:

Zitat von Frickler (Beitrag 1361683)

fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern.

So versuchen wir es fast immer zu machen. Der große Vorteil für uns ist, daß es vollkommen egal ist, mit was der Kunde auf die Daten zugreift - die Daten sind in jedem Fall konsistent.
Außerdem ist damit unserer Erfahrung nach eine viel sauberere und konsequentere Umsetzung von Transaktionen möglich - was wieder Inkonsistenzen verhindert.

Und dann wär da noch der Geschwindigkeitsvorteil - sauber designte und umgesetzte Logik in der DB ist gerade wenn's nicht nur im LAN laufen soll ein enormer Geschwindigkeitsvorteil.

Was immer wieder als Argument dagegen herhalten muss ist der Wechsel des DBMS. Würde ich aber sowieso nie machen - weil man sich dann in allem was man macht immer auf den kleinsten gemeinsamen Nenner einigen muss und damit viel an Unterstützung und Geschwindigkeit die das DBMS bietet liegen lässt.

Zitat:

Zitat von Frickler (Beitrag 1361683)

In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.

Genau. Mit keinem der beiden Ansäzte lässt sich gänzlich alles abdecken.

Luggi

[Lemmy]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361690)

Zitat:

Zitat von Lemmy (Beitrag 1361688)

Denn StoredProcedures, Views und co. lassen sich ziemlich schlecht in Unit-Tests überprüfen. Code in Objekten dagegen sehr gut.

Dazu kommt noch, daß damit ja ein Teil der Sourcen in der Datenbank des Kunden vor Ort abgelegt wird. Das ist bei Updates auch ein nicht zu unterschätzender Aufwand. Immerhin kann der Kunde ja auch mal eben eine alte Datensicherung wieder einspielen - mit den dann veralteten Stored Procedures.

lässt sich recht einfach damit umgehen: In der DB ist ne Version gespeichert, erwartet die Anwendung eine neuere Version, werden die entsprechenden Updates eingespielt (mit entsprechenden Absicherungen).

[hoika]

Hallo,
ich stimme meinen Vorrednern zu, ausser das hier

Zitat:

Puristen verzichten sogar auf JOINs und machen auch das in der Anwendung.

Purist müsste durch "Kafeetrinker" ersetzt werden,
weil ohne Joins es manchmal doch ziemlich lange dauern könnte,
die Join-Tabelle muss ja auch erst in Objekte geladen werden.

Unit-Tests lassen sich auch mit Testdatenbanken machen,
ist aber in der Tat sehr viel aufwendiger als Objekte.

[Mavarik]

Ich denke auch, es gibt mindestens 2 Sichten...

Kleine Anwendung:
- Datenbank dumm
Größe Anwendung
- Schlaue Datenbank

Warum?
Wenn ich alles selber mache... Ist mir fast egal welche Datenbank dahinterliegt.. Könnte auch ein Bin-Writer sein, der die Daten einfach hintereinanderschreibt und ein Index hat. Klassische ISAM.

Stell dir vor es arbeiten aber 1000 Leute oder mehr auf der Datenbank... Da hat der Leiter des Rechenzentrum Millionen ausgegeben, damit die Datenbank vernünftig skalieren und du machst alles auf dem Client PC...

Mavarik

PS.: Und klar das Schichtmodell in der Anwendung. Die darf gar nicht wissen welche Datenbank genutzt wird...