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

[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 von Lemmy:

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]

Zitat von Uwe Raabe:

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 von Uwe Raabe:

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

Und bei einem Wechsel des DBMS der absolute Horror

[Lemmy]

Zitat von Uwe Raabe:

Zitat von Lemmy:

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

[haentschman]

Moin...

Zitat:

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.

Ich bevorzuge auch diese Variante.

Zitat:

ansonsten alle Zugriffe programmgesteuert vornehmen:

Das gilt nur für die Anfrage an die Datenbank und dem Lesen des Ergebnisses. Wie die Datenbank zu dem Ergebnis kommt über SP o.ä. ist ihr Bier.

Zitat:

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.

Persönlich mag ich keine Programmlogik in der DB. "Zitat: Das ist bei Updates auch ein nicht zu unterschätzender Aufwand" Die Datenbank speichert Datensätze die "normalisiert" sind. Die einzige Aufgabe ist für die Datenbank seine eigene Konsistenz zu schützen.
Frage: Wo ist der Unterschied von Progammlogik und Datenbanklogik bei Euch? Ist eine SP schon Programmlogik?

Zitat:

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

...so sieht es aus. Die Anwendung darf nicht wissen wo ihre Daten herkommen.

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

[nahpets]

Ich frag' mich immer wieder: Wieso sind eigentlich Datenbanken so leistungsfähig, wenn die Nutzer doch alles selbst in ihren Programm "nachprogrammieren"?

Hat man mit vielen (sehr vielen) Daten zu tun, so ist es durchaus sinnvoll die Logik in die Datenbank zu legen. Das kann zu Laufzeitersparnissen im Bereich von Stunden und Tagen führen.

Datenbanken sind dahin optimiert mit Daten umzugehen. Warum soll ich mir alle Daten in den Arbeitsspeicher holen und dort dann die in der Datenbank bereits vorhanden Logik zum Umgang mit vielen Daten nachprogrammieren?

Meine Devise (aus langer Erfahrung mit extremen Datenmengen) ist: Lass alles die Datenbank machen, was die Datenbank machen kann. Sie kann das mit Sicherheit besser, als ich es in meinen kühnsten Träumen nachprogrammieren kann.

In Programmen mache ich nur das, was die Datenbank nicht mit eigenen Mitteln (einschließlich der von mir geschrieben Datenbankprozeduren ...) nicht erledigen kann.

Ansonsten sind die Programme nur zur Steuerung der Datenbank und der Anzeige der Daten für den Nutzer zuständig.

Aber wie immer:

Es gibt verschiedene Möglichkeiten. Für 'ne Adressverwaltung (auch anspruchsvolle) u. ä. ist es sicherlich nicht sinnvoll, groß Datenbanklogik zu schreiben, wenn man's auch mal eben im Programm machen kann. (Oder Datenbankunabhängigkeit eine Voraussetzung ist.)
Oder die Software muss bei Kunde X gegen Datenbank O, laufen, bei Kunde Y gegen M, bei Kunde Z gegen wasweißich, dann gehört die Logik (fast schon zwansläufig) ins Programm.

Aber gerade bei Mengenverarbeitungen, die nicht mal angezeigt werden müssen (also klare Batchanwendungen) sind gute Datenbanken dem "Eigenbau" an Leistungsfähigkeit und Performance klar überlegen.

Es kommt letztlich also darauf an, was man denn da so eigentlich will.

Geschäftlogik lässt sich wunderbar in Triggern "abarbeiten". Der Vorteil: Es ist egal, auf welchem Weg die Daten in die Datenbank kommen. Die Logik zieht immer.

Und bezüglich Datenbankwechselhorror:

Wenn ich mich zu Beginn der Entwicklung für eine Datenbank entscheide, dann ist das so grundsätzlich, dass ein Wechsel danach nicht mehr in Frage kommt, es sei denn, man entwickelt ein System neu.

Und Updatehorror mit veralteten Prozeduren:

Entweder man sichert ein System vollständig und hat dann bei 'nem Restore einen konsistenten Stand oder man sichert nur die Daten und schreibt die bei 'nem Restore zurück.

Wer bei 'nem Restore nur aktuelle Daten hat, aber mit denen veraltete Datenbankroutinen zurückschreibt, hat irgendwo gewaltigen Bockmist verbrochen.

Mir ist noch kein Fall untergekommen, bei dem, in einem vernünftig verwalteten System, nach 'nem Restore Inkonsistenzen bezüglich Daten und Datenbankroutinen entstanden sind.

Zuweilen formuliere ich es immer mal wieder ein bisserl flapsig:

Wer alle Logik ins Programm packt und die Datenbank nur für die pure Datenhaltung nutzt, der kann seine Daten dann auch in CSV-Dateien schreiben und das bisschen Abfragelogik noch selbst implementieren.

Mal so als Beispiel:

Man benötige ein paar Aggregatfunktionen für sagen wir mal so ca. 200.000.000 Datensätze aus 'nem halben Dutzend Tabellen.

Man lade das dann bitte alles in sein Programm und mache mal.

Alternative: Man schreibe dazu die passenden Views und Datenbankprozeduren.

Welcher Weg mag bei der Ausführung dann letztlich der schnellere sein?

Habe noch keine Situation erlebt, in der die Datenbank nicht um längen (Stunden bis Tage) schneller war.

Und wer Angst bezüglich veralteter Datenbankprozeduren ... hat:

Die Datenbanklogik unterliegt selbstverständlich genauso einer Versionierung, wie die übrige Software.
Und das wird alles grundsätzlich konsisten ausgeliefert.

Alles andere wäre stümperhaft.

@grl: Jo, so ist es, Deiner Aussage ist eigentlich nichts mehr hinzuzufügen.