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

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

[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

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

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

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

[mensch72]

"(Client)Programm dumm + (Server)DB schlau" contra "(Client)Programm schlau + (Server)DB dumm" ... da gibt es doch noch was... die Multi-Tier-Architektur:


- die (Server)DB kümmert sich um Datenhaltung incl. Backup&Restore, (Änderungs&Zugriffs)Protokolle, Schreibrechte und transaktionsbasierte physisch (Referenzielle)Datenintegrität
- die logische Funktionalität, also BusinessLogik steckt im APP-Server, der physisch möglichst nah neben/auf dem DB Server im Backend läuft... (erst)hier wird die relational DB Struktur in ein Objekt(relationales)Daten&Funktionsmodell abstahiert. Alle StandardClients greifen nur auf den APP Server zu. Systemtools und Volumen-Interfaces können auch parallel zum AppServer direkt innerhalb des Backenend mit dem DB Server arbeiten
- viele "dumme" Clients arbeiten nur mit dem APP-Server, denen ist somit die verwendete DB völlig egal
- wenige "intelligente" Clients oder Interfaces können innerhalb des Backend auch direkt mit den DB Daten sehr effektiv lesend arbeiten, und ihre Schreibzugriffe sind/werden nach Rechtevergabe von der DB selbst abgesichert... 90% unserer Kunden fühlen sich einfach gut, wenn sie notfalls mit Tool XY selbst mal lesend ohne viel Administrationsaufwand auf IHRE Basisdaten zugreifen können... wirklich "selbst schreiben" wollen nur ganz wenige in die DB, und wenn dann sind es meist Kopplungen von Fremdsystemen, wo deren Anbieter gerne etwas automatisieren wollen... und genau solche Schnittstellen realisieren wir DB intern mit Triggern und allen uns notwendig erscheinenden Validierungen. "Unsere Hauptlogik" steckt im APP-Server und verlässt sich nur auf stimmige von der DB garantierte (Referenzielle)Datenintegrität.


ps:
"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."
Ein paar Zeilen vorher hat jemand von Zugriffen auf 200Mio Datensätze geschrieben, wo er Standard DB bevorzugt... wir machen es da genau anders: ab 24Mio Datensätzen arbeiten wir mit eigenen externen BlockBinaryFiles, welche wir per Trigger konsistent über native DB-AddON schreiben, aber 100% selbst lesend binär im APP Server verarbeiten. Im Finanzumfeld haben wir "mehrfach" hunderte Mio von Datensätzen pro Datenbestand(z.B. auf die Millisekunde genau alle Währungstransaktionen der 9 Hauptwähungen der letzten 10Jahre... das sprengt jeden Standard-SQL-DB-Server)

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

[nahpets]

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.

Sagen wir mal so: Datenbanklogik schließt nicht aus, dass sie Geschäftslogik ist.

Für mich ist Datenbanklogik der Teil der Geschäftslogik, der in der Datenbank liegt und von der Datenbank ausgeführt wird.

Auch Views sind für mich ein Teil der Geschäftslogik. Sie stellen halt eine definierte Sicht auf die von der Datenbank vorgehaltenen Daten dar.

Für mich gehört alles in der Datenbank, was nicht der reinen Datenvorhaltung dient, zur Geschäftslogik.

Unter Datenvorhaltung verstehe ich hier (mal unfein ausgedrückt): "CSV-Dateien auf hohem Niveau"

Zitat von Slipstream:

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.

Jain: Sagen wir mal so: Man kann alles auf die Datenbank verlagern, was die Datenbank mit Datenbankmitteln erledigen kann.

Habe mal Routinen geschrieben, mit denen man bei Adressdaten auf Ähnlichkeiten achtet, um die Anlage von Adressdubletten (möglichst weitgehend) zu vermeiden (quasi ein extrem aufgemotztes SoundEx und sonstige Phonetikvergleiche ... Gewusel). Das geht mit der Datenbank, man muss halt die Programmiersprache der Datenbank genauso beherrschen, wie man's von Delphi nach jahrelanger Erfahrung gewohnt ist.
Da müssen dann halt ein paar Datenbankpackages her. Dazu ein paar Funktionen, die auch in Triggern aufgerufen werden können und plötzlich ist es egal, wer aus welcher Quelle, welche Daten in das System schubste: Dubletten werden erkannt, bei Unsicherheit protokolliert und der Fachabteilung frisch zubereitet zur Überprüfung vorgelegt.

Und das ganze läuft auch noch sauschnell. Dieses Tempo hat keine der vorherigen Programmlösungen (auch keine der seinerzeit kaufbaren) hinbekommen.

Und SQL schreibt man nicht mal einfach so. Man muss schon eine entsprechende Denkweise erlernen, um sinnvoll und performant Daten aus einer Datenbank heraus bzw. hinein zu bekommen. Da braucht man mehr als nur die Kenntnis der korrekten Syntax. Man muss nicht nur das Datenmodell kennen, sondern möglichst das Datenmodell incl. der zugehörigen Fachlichkeit. Hat man das zusammen, dann kann man sich zuerstmal überlegen, wie die fachlichen Zusammenhänge zwischen den auszuwertenden / verarbeitenden Daten sind und damit dann anfangen ein möglichst performantes SQL zu formulieren. Ein "select * from tabelle left right full wasweißichjoin order by 1,2,3,4" ist da oft nicht unbedingt die erste und beste Lösung.

Zitat von Slipstream:

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.

Das Glück hatte ich auch bei zwei großen Projekten. Solche Leute sind schlicht und einfach Gold wert und leider eher selten zu finden.

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