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

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

[Slipstream]

Zitat von nahpets:

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

Vielleicht gehts ja vielen so wie mir: ich konnte mich nie so richtig mit SQL anfreunden und habe früher auch immer alles im Programm erledigt, was eigentlich auch die Datenbank machen könnte. Zum Glück arbeite ich seit Jahren in einem Team mit einen hervorragenden Datenbankspezialisten, der nicht nur einfach alles übernimmt, was an SQL-Programmierung nötig ist, sondern seinen Kollegen auch geduldig erklärt, wie eine bestimmte SP arbeitet.

Zitat von nahpets:

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.

Sagt mein Kollege auch immer, wenn mal wieder einer versucht, die Datenbank nachzuprogrammieren

Zitat von nahpets:

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

Alles kann man natürlich nicht in Stored Procedures legen. Wir haben zum Bleispiel ein Textanalyse-Machine, das nicht nur Rechtschreibung und Grammatik korrigiert, sondern auch Synonyme kennt, Worthäufigkeiten ermittelt und der Gleiches mehr. Das kann man mit DB-Mitteln nicht realisieren.

Zitat von nahpets:

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.

Genau. Und deshalb ist es nicht correct zu sagen, man muss alles in der DB machen oder alles im Programm. Vielleicht sind manche Programmierer, die ihr halbes Leben an ihrer einzigen grossen Anwendung, die ihnen den Lebensunterhalt sichert, herumschrauben, mit der Zeit ein wenig im Blick verengt worden und könnten sich dann nicht mehr vorstellen, dass es auch andere Anforderungen gibt. Kleinaufträge müssen bei uns immer rapid entwickelt werden, das ist dann meistens meine Spezialität (deshalb auch manchmal die Nachtschichten), dass das schnell über die Bühne geht, das ist so zu sagen eines unserer Aushängeschilder, wir liefern kleinen Kunden (der letzte war fast zwei Meter gross) kleine Programme sehr schnell. (Sagt mein Kollege immer, wenn so ein Langer kommt: "Die Tür ist nur bis 190 erlaubt, du musst leider den Liferanteneingang benutzen."

Zitat von nahpets:

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.

Kann ich bstätigen.

Zitat von haentschman:

Zitat:

Wir haben auch recht viel der Buissineslogik in der DB

mal ne dumme Frage...
Zählt eine SP zur Businesslogik (was man auch im Programm abarbeiten könnte) oder zur Datenbanklogik die eine Abfrage "berechnet".
Vieleicht sollte man das mal definitionstechnisch klarstellen.

Wieso ist das wichtig? Zählt ein Virus noch zu den Tieren oder ist er ein Pflanze? Oder eine Alge? Damit kann man gut streiten, aber es ist doch nicht wichtig, oder?

[haentschman]

Hallo Slipstream,
ich weiß ja nicht womit ich dir auf die Füße getreten bin? Weil ich in dem anderen Thread nicht deiner Meinung war?

Zitat:

Wieso ist das wichtig? Zählt ein Virus noch zu den Tieren oder ist er ein Pflanze? Oder eine Alge? Damit kann man gut streiten, aber es ist doch nicht wichtig, oder?

...für solche dummen Kommentare bin ich grad zu haben.

[Slipstream]

Zitat von haentschman:

Hallo Slipstream,
ich weiß ja nicht womit ich dir auf die Füße getreten bin? Weil ich in dem anderen Thread nicht deiner Meinung war?

Zitat:

Wieso ist das wichtig? Zählt ein Virus noch zu den Tieren oder ist er ein Pflanze? Oder eine Alge? Damit kann man gut streiten, aber es ist doch nicht wichtig, oder?

...für solche dummen Kommentare bin ich grad zu haben.

Tut mir leid ich fühle mich nicht auf die Füssen getreten. Und dumm bin ich auch nicht, zumindest sagt das meine Frau immer: Du bist doch nicht dumm, machs doch richtig. Also glaub ich meiner Frau lieber als dir, den ich nicht kenne. Ich find meine Kommentare nicht dumm, sondern bildhaft. ich versehe nicht, wieso ich jetzt auf deinen Füssen stehen soll. Über diese Sachen Tier oder Pflanze streiten sie wirklich, die Wissenschaftler, das hab ich nicht erfunden.

Zitat von nahpets:

@haentschman
Slipstream wollte mit seinem Virus-Tier-Pflanzenvergleich (vermutlich) nur eine Analogie zwischen Business und Datenbanklogik herstellen. Die Grenzen sind fließend und können nicht absolut festgelegt werden. Es gibt halt auch hier immer etwas, das man ohne schlechtes Gewissen in beide "Töpfe" stecken kann. Es ist einfach kein reines "Schwarz-Weiß" zwecks Unterscheidung möglich. Oder eben keine klare und eindeutige Unterscheidung zwischen Tier und Pflanze. Ich persönlich halte es auch nicht für wichtig, streng zwischen Geschäfts- und Datenbanklogik zu unterscheiden. Im Vordergrund steht für mich eine möglichst perfekte Funktionalität der umzusetzenden Anforderungen.

Danke für diese Hilfe, Pflanzen und Tiere sind beide aus Einzellern Bakterien entstanden, wie man heute weiss, deshalb kann man bei diesen frühen Lebewesen nicht festlegen, ob Tier oder Pflanze. Du hast mich genau richtig verstanden, es ist nicht wichtig dass man immer genau zu unterscheiden kann zwischen Datenbank- und Anwendungslogik. Man kann aber prüfen, ob das eine oder das andere besser ist in jedem speziellen Fall.

Ich habe irgendwie den Eindruck, Fremde sind hier nicht so gerne gesehen, oder? Ich spüre ein wenig Feindseligkeit und verstehe das nicht. Aber egal, ihr werdet mir schon sagen, wenn ihr mich nicht hierhaben wollt, stimmts? Vielleicht bin ich auch nur zu viel Freundlichkeit den ganzen Tag verwöhnt und habe verlernt, wie es in Deutschland ist. ich weiss es nicht.

[haentschman]

Dann ist es ja gut.
Mir ging es nur darum, das wir alle über das Gleiche reden.