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

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

[bernau]

Auch von mir ne kurze Antwort:

Wenige verschiedene Programme, die auf die Daten zugreifen. Am besten alle Programme mit der gleiche Buisness-Ligik-Unit. Dann kommt die Logik in's Programm. DB bleibt dumm.

Viele Verschiedene Programme, unterschiedlichster Herkunft, die auf die DB zugreiffen, dann die Logik in die DBMS. Man weis doch sonst nie, wer den Fehler verbockt hat.

[jobo]

Zitat von 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.

Debuggen kann ich auch die SP, wenn es von den Tools unterstützt wird. Freilich kenne ich auch keins, das es durchgängig macht (Clientcode plus SP).
Aber: ich kann in SQL ellenlange Testscripts schreiben, SP aufrufen bis der Arzt kommt, inkl. Prüfviews usw. und wenn das Ergebnis falsch ist, sag ich rollback und korrigiere die SP oder den View.
Auf diese Weise kann ich tatsächlich komplette Business Prozesse abbilden. Daher ist mir das "Unittesting" Argument auch nicht so klar.

Was komplexe Anwendungen angeht, OCR, Thesaurus und Co, da kann ich nur empfehlen, sich mal die Leistungsfähigkeit führende DB Anbieter plus Erweiterungen anzusehen.
SEPA XML mache ich per SQL, Excel lese ich per SP.
Und falls ich es noch nirgendwo erwähnt hatte PostgreSQL finde ich ist ein Spitzensystem. Dafür würde ich sogar Geld ausgeben, aber es ist leider kostenlos.
PostgreSQL ist im Übrigen auch ein gutes Argument gegen das "Du kannst nicht wechseln". Ich schätze, dass man eine Mehrheit von Oracle Systemen durch PG ersetzen kann, mit überschaubarem, also kalkulierbaren Aufwand und vertretbaren Kosten. Ähnlich sieht es vielleicht bei anderen Systemen aus.
Es gibt sehr abgefahrene Features in manchen DB, Systeme wie von Oracle müssen sich ja irgendwodurch auszeichnen und all das Schmerzensgeld rechtfertigen, z.B. sowas wie Multitenancy, Versionierung von Logik oder andere Sachen. Aber in der Praxis habe ich davon noch nichts eingesetzt.

[jfheins]

Ich verwende liebend gerne das Entity Framework.

Im Wesentlichen baut man seine Klassen so auf, dass eine Klasse einer Tabelle in der DB entspricht. Das genaue DBMS ist dabei zweitrangig (aber nicht ganz unwichtig)
Nun hat man einen DataContext (= Datenbankschema) auf das man Abfragen durchführen kann.

Joins, Where-Einschränkungen und Spaltenauswahl wird dabei im Code definiert, die SQL wird generiert und an die Datenbank weitergereicht. Zurück kommen die Klassen, die man den Tabellen zugeordnet hat. Die Datenbank hat so viele Constraints wie sinnvoll um die Datenintegrität sicherzustellen. Also explizite Foreign-Keys und Unique Indices.

Insofern ist die Datenbank eher "dumm", weil sie keine SP und Trigger enthält, aber natürlich werden Joins in der Datenbank abgewickelt.

Beispiel:

Code:

public IQueryable<Bar> FilteredBars(int user)
{
   return from bar in Bars
         join foo in Foos on bar.ID equals foo.ID
         where foo.List == null || foo.List.Items.Any(item => item.UserID == user)
         select bar;
}

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