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.