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.

[grl]

Zitat von Frickler:

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 von Frickler:

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

[p80286]

Zitat von grl:

Zitat von Frickler:

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 von Frickler:

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

Aus meiner Erfahrung heraus, der Weg die Daten sauber zu halten, ist die "schlaue Datenbank". Was natürlich in der Entwicklung relativ aufwendig ist, da RAD und Selbstdokumentation nicht zu den bevorzugten Zielen der DB-Entwickler zählen. Storage and Retrieval ist der Job von Datenbanken, darum sollte man sie auch ihren Job machen lassen.

gruß
K-H

[Rollo62]

Ich nutzt StoredProcedures zwar auch nicht wirklich, wollte da aber immer mal ran.
Den Vorteil sehe ich vor Allem auch in eriner "robusten" DB, die man mit normalen Zugriffen nicht zerstören kann.
Sie kann sich selbst immer valide halten.

Ich denke das ist auch ein nicht zu unterschätzenden Vorteil der schlauen DB.

Aber der ganze Aufwand ....

Naja, wenn ich mal mehr Zeit habe schau ich mir das nochmal an, solange bin ich im Moment bei CRUD mit REST und JSON.
Einfach ist auch meistens gut (wenn auch kein Ferrari).

Rollo

[himitsu]

Wir haben auch recht viel der Buissineslogik in der DB, aber auch einen Teil in Komponenten (Ableitungen 'ner DataSource+DataSet) und dann noch viel in den Forms (Letzeres vorallem bei alten gewachsenen Formularen)

Unsere Dokumente (Images, PDFs usw. liegen in einer eigenen Serveranwendung) und das dann auch noch transaktionssicher hinzubekommen, wenn man ein Dokument aufnehmen oder verändern will und einem da nicht nur der Code der Forms, Klassen und auch noch der Trigger dazwischenfunken tun ... hat Wochen gedauert und ich bin mir sicher, dass es noch Lücken gibt.

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

[hanvas]

Zitat von Frickler:

Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren...

In manchen Datenbankbüchern wiederum wird gern das umgekehrte Prinzip beschrieben...

Das eine schließt das andere nicht grundsätzlich aus und beide Vorgehensweisen haben Ihre - je nach Anwendungsfall - Berechtigung. Abgesehen davon gibt es ja auch noch Zwischenformen wenn man einen Applikationsserver dazwischenschaltet.

Die Datenbank die Arbeit machen zu lassen hat zunächst einmal den Vorteil das wenig Daten bewegt werden. Wenn ein Client lokal auf eine DB zugreift ist das meist unwichtig, und auch in einem kleineren Netzwerk führt das nicht zu Problemen - wenn aber eine entsprechend große Anzahl an Clients über unterschiedlich schnelle (und manchmal langsame) Übertragungswege auf eine DB zugreift kann jedes gesparte Byte zählen.

Das ist ja der Grund warum man relationalen Datenbanken meist in 3 oder höheren Normalform entwirft, um eine minimale Anzahl an Bytes zu haben die bei jeder Transaktion gelesen, geschrieben oder transportiert werden müssen.

Der zweite Grund der für eine zentralisierte Datenhaltung spricht ist die Tatsache das ein Wildwuchs an Clients die Daten nicht zwangsläufig zerstört. Zwei Clients in unterschiedlichen Versionen greifen bei einem sauberen Design dennoch definiert zu.

Einfache Skalierbarkeit und Ausfallsicherheit (beispielsweise via. Replikation) sind ein weiterer Grund für eine zentralisierte Datenhaltung.

So lange es nur um das Lesen und Schreiben von Objekten geht wiederspricht Deine im Ursprungsposting gemachte Anmerkung Objekte beispielsweise in Listen einzulesen und nur auf diesen Listen zu operieren dem nicht. Lediglich wenn die gleichen Daten von der DB und dem Client manipuliert werden kann es einen Wiederspruch zwischen beiden Modellen geben. Aber dann kann man sich behelfen.

Nach meiner Meinung gehören Operationen die dazu dienen die Normalisierung der Datenbank sicher zu stellen und/oder die dazu dienen nur definierte Schnittstellen (Views, Funktionen, Prozeduren) anzubieten in die Datenbank, das gleiche gilt für Operationen deren Hauptzweck die Datenintegrität ist, ebenso Replikation, Logs etc, da hier von der Client nichts wissen muss.


Operationen oder Geschäftsregeln (in dem Sinne von wenn ich eine Position mit einer Menge von 5 einer Ausgangsrechnung hinzufüge dann verringert sich der Lagerbestand um 5) kann man sowohl in das Datenmodell packen wie auch in den Client. Der Client hat den Vorteil das man flexibler ist, aber eben auch mehr Mist anstellen kann. Da Du aber nach einem Schichtenmodell gefragt hast kannst Du die Schicht mit den Geschäftsmodellen auch in einen App-Server auslagern.

Mit manchem Frameworks geht das recht einfach. Im Moment bin - zumindest bei Delphi - ziemlich begeistert von TMS Aurelius. Fast alles was ich gerade eben beschrieben habe funktioniert damit sehr transparent.

cu Ha-Jö


* Ich hole mir immer das/die Objekte mit dem ich gerade arbeite (und keine anderen) über eine Abfrage. Dabei werden immer so wenig Objekte wie möglich (aber so viele wie nötig) eingelesen und die Liste wächst im Arbeitsspeicher - ändere ich ein Objekt dann wird dieses Objekt (und nur dieses) wieder zurückgeschrieben.