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

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

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

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

[himitsu]

Was man gegen die Logik in der DB sagen kann, ist das Debuggen des Programms.
Gut, es ist zwar bei vielen DBMS auch möglich das zu machen, aber "zusammen" mit dem Programm dann halt nicht, alles in einem Debugger.

Zitat:

Das kann man mit DB-Mitteln nicht realisieren.

Das geht schon, denn viele DBMS bieten es an, dass man Fremdfunktionen einbinden kann.
Da wird eure Funktion dann wir eine normale SP aufgerufen, bzw. wie die BuildIn-Funktionen ala TRIM oder COALESCE.
Ihr schreibt eine DLL z.B. mit Delphi, veröffentlicht eure Funktionen (Exports) und bindet das dann ins DBMS ein.

[jobo]

Zitat von haentschman:

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.

Businesslogik sind in meinen Augen fachliche Anforderungen, die man nicht unbedingt mit gängigen Datenbankmitteln abdecken kann. Bis hin zur Implementierung von ganzen Geschäftsprozessen.
Beispiel Kundenverwaltung, ich kann Anrede Herr, Frau, (Fräulein) usw. als Constraint definieren, habe aber ein Problem, sobald die Marketingabteilung meint, da muss jetzt auch GenderQueer rein. Und übermorgen stellt man fest, das man 2 vergessen und 3 falsch geschrieben hat.
Also muss es entweder modelliert werden, Anrede Tabelle mit Schnickschnack oder ich streue regulierenden Code ein (Trigger, SP), die eingreifen.
Wenn ich meine CRM Software nun an verschiedene Kunden verkaufen möchte, läuft es darauf hinaus, dass es so gemacht werden muss, dass die es selber einstellen können. Fachliche Anforderungen werden in ein möglichst dynamisches DB Modell umgesetzt.
Trotzdem hindert einen niemand daran, Anrede halt doch per Constraint zu definieren.
Den Begriff aufzudröseln ist nicht immer einfach.

So wird ein Schuh draus:
Wenn ansatzweise die Möglichkeit besteht, dass verschieden schlaue Clients auf die DB zugreifen (schreibend), dann empfiehlt es sich alles wasserdicht zu machen, was davon betroffen ist. Das sorgt dann für Robustheit. Ein Appserver der nicht über das alleinige Zugriffsrecht verfügt, wird da eben zum Risiko. Ein schlauer Client allein nicht. Aber wenn ein Systemzugang einmal offen ist (nur für ein paar Access Reports) und die Schreibrechte ungeregelt, dann hat man m.E. die Kontrolle verloren und kann tatsächlich gleich mit Excel weiterarbeiten.

[MichaelT]

Die Welt ist grau.

In dem Zusammenhang wird tatsächlich von Business Logik gesprochen. Sobald man so in die Ecke 4GL reinschnuppert...

Eine persistente Abfrage welche ein Ergebnis liefert ist eine Query. Eine Query ist ähnlich einer View, eigentlich eine parametrierte View. Der SQL Server bildet Querys relativ exakt entlang dieser Definition ab.

In Österreich verwenden wir den Begriff Query eher im Kontext TQuery.SQL nämlich der SQL Abfrage. Delphi Query ist eine selche View, deswegen ist sie in einem Datamodule an sich ganz gut aufgehoben. Eine Query wäre dann schon Teil der Business Logik. In dem Zusammenhang kann die Verwendung einer SP, selbst wenn sie einfachste Aufgaben erfüllt (Konvertieren einer Auftragsnummer zum Zwecke der Präsentation oder dem Export) Teil der Businesslogik werden.

Sie leidet am selben Trouble der immer wieder für Diskussion sorgt. Sie schreiben in der Regel nicht im Rahmen *einer* Anwendung auf eine DB.

Fast alle Delphi DB Komponenten haben mit DB im Kontext dieser Diskussion nicht viel zu tun sondern wären Teil der Businesslogik.

Solange allein ein Informationsmodell absicher gegen den Missbrauch durch eine Applikation (Schutz des Informationsmodell) sind sie in der Regel im Umfeld der Business Logik.

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.