Best Practises Nachfrage

[KingofKning]

Hallo *all,

wie ich ja aus dem SQL Thread entnehmen kann sind ja die Profi-Programmierer vehement dagen die sog. Buisiness-Logik im SQL zu hinterlegen.

Warum?
Ich als alter Cobol-Programmierer habe mir immer gewünscht das ich eine gewisse Logik in der Datenbank hätte und nicht immer irgenwelche SUB-Programme aufrufen muß um z.B. Preise die von Wechselkursen abhängig sind zu ermitteln oder oder. Der Beispiele gäbe es ja viele.
In Progress (4 GL Sprache / SQL ähnlich) haben wir damals vieles dort hinterlegt.

Welche Argumente gibt es also die Sagen: Buisness Logik nur im Programm.

Schönes Wochende.

GG 2535

[Andreas_Prouza]

Wie ich im vorherigen Thread schon erwähnt habe, hat für mich Business-Logik nichts mit der Sprache zu tun.

Grundsätzlich sollte man (so weit es möglich ist) eine Trennung der Ebenen DB <--> Prozess/Business-Logik (damals PGM) <--> GUI ansetzen.
Ich schreibe Prozess statt PGM, da auch SQL Views dort hineinfallen können.

Eine View, die Daten entsprechend aufbereitet (z.B. Wechselkurs Berechnung, Erzeugung von JSON, usw.) gehört für mich hier in den Bereich "Prozess".
Diese View greift gleich wie alle anderen Prozesse/Programme auf die DB zu. (Am Besten via Views).

Man sollte also die Unterteilung der Ebenen nicht an eine Sprache festnageln sondern wofür es verwendet werden soll.

Am Ende des Tages geht es darum, dass man sich nicht selbst ein Loch gräbt.

Dieter Bender hatte damals bei der Common Europe in Wien einen Vortrag gehalten und von einem Projekt erzählt junger Entwickler, die XML als Schnittstelle für Programmaustausch (im Detail kann ich mich nicht mehr erinnern) einsetzten.
Er erzählte, dass diese Leute so gut wie alles falsch gemacht hatten, was man in der Zeit als "absolutes No-Go" abgestempelt hatte.
Dieses Design der Entwickler war jedoch modern, einfach erweiterbar, schnell und wartungsfreundlich.
Ein super Beispiel dafür, dass man "Regeln" immer wieder reflektieren, erweitern/ändern und an die aktuelle Technologie anpassen muss.
Dieses Beispiel fand ich sogar als das Wertvollste was man dort mitnehmen konnte, da es Zeitlos ist.

[BenderD]

... bei Schichtentrennung strebt man zunächst Technologie Unabhängigkeit an. Eine Applikation sollte weder von der Frontendtechnologie noch von der Datenbank abhängen. Das mit dem Frontend ist mittlerweile durch, die Abhängigkeit von der Datenbank hat die meisten Anbieter von AS/400 Anwendungen in den Ruin getrieben und hat mittlerweile fast alle Unternehmens-spezifischen Entwicklungen im AS/400 Bereich abgeräumt.

Wenn man das erstmal außen vor lässt (nach dem Motto: AS7400 muss sein, der Rest ist mir egal), dann bleiben immer noch Wartbarkeit und Änderungshäufigkeit von Komponenten, die eng zusammenhängen.
Die meisten Änderungen sind im Frontend (... ich hätte da gerne noch dieses oder jenes angezeigt), was sich am wenigsten ändert ist die Datenhaltung (hier werden sogar ernsthafte Designfehler fortlaufend mit hohem Aufwand bezahlt - der Lieferant im Artikelstamm lässt grüßen).

Zu den Komponenten mit Ämderungspotential gehören gerade die Komponenten, die gerne in die Datenbank geschoben werden (die Preisfindung hast Du selber genannt), wobei die enge Kopplung zwischen Daten und Logik dann zu höherem Wartungsaufwand und Fehleranfälligkeit führen. Hier ist die Frage von dem anderen Dieter bezeichnend (wie kann ich das debuggen).

Natürlich gehören die Business-Regeln erst recht nicht mit der Präsentationslogik verknotet - wie häufig in RPG Anwendungen zu sehen), das ergibt aber kein Argument, das in die Datenbank zu schieben.

Wenn ich das ganze aus der Sicht Restrukturierung einer vorhanden Anwendung betrachte, ist die Verlagerung von Bisuinesslogik in die Datenbank noch fataler, das dies Restrukturierung und Redesign im Bereich Datenbank nahezu verunmöglicht.

D*B

[Fuerchau]

Ergänzend dazu:
XML und JSON sind Schnittstellendokumente die eben auch mit vielen Methoden erstellt/verarbeitet werden können.
SQL ist da eine der Schlechtesten, da SQL relational ist und XML/JSON hierarchisch.
Die Verarbeitung von XML/JSON ist in anderen, objekt basierenden, Sprachen erheblich einfacher, da ich das Dokument nicht relationalisieren muss.
Sowohl zum Lesen als auch zum Erstellen gibts da halt bessere Methoden.
Die regen Beispiele, auch aus SQL-Server, lassen sich im Code erheblich einfacher verwenden und sind da auch erheblich schneller zu erstellen.
SQL muss da rege Klimmzüge machen um Beziehungen zwischen den Hierarchien mittels Join herzustellen. Im Objektmodell habe ich da Direktzugriffe drauf.

Aber warum ein Programm schreiben, wenn SQL es doch auch kann.
Das sagen dann die, die eher SQL als programmieren können oder noch nicht die richtige Sprache beherrschen;-).

Das ist meine ganz persönliche Sicht, Erfahrung und Meinung.

[camouflage]

@Baldur,
meines Erachtens geht die ganze Sache noch viel weiter, vor allem wenn Dokumente in's Spiel kommen. Hier finde ich eine relationale DB völlig ungeeignet. Wer sich mal mit MongoDB beschäftigt hat, weiss was ich meine. Und ja, ich bin Fan von dieser DB, weil dagegen die SQL Datenbanken ziemlich alt aussehen.

[BenderD]

@Baldur,
meines Erachtens geht die ganze Sache noch viel weiter, vor allem wenn Dokumente in's Spiel kommen. Hier finde ich eine relationale DB völlig ungeeignet. Wer sich mal mit MongoDB beschäftigt hat, weiss was ich meine. Und ja, ich bin Fan von dieser DB, weil dagegen die SQL Datenbanken ziemlich alt aussehen.

... am Thema vorbei, setzen 5!

... ich nehme mal meinen eigenen Raunzer zurück, sorry Karl.
Im Grunde genommen ist das ein gutes Beispiel für Schichtentrennung und was in die Datenbank an Logik gehört und was nicht.

Dokumente sind hierarchisch geordnete Daten, deren Struktur nicht uniform festgelegt ist (wie in relationalen Datenbanken). Bei sauberer Schichtentrennung, habe ich in der Applikationsschicht ein Objekt (in prozedural gedacht und in ILE formuliert ein Serviceprogramm), das so ein Dokument oder eine Klasse von Dokumenten repräsentiert.

Jetzt brauche ich Methoden (in ILE gedacht exportierte procedures), die eine Dokument aus der Datenbank laden, bzw. in der Datenbank speichern können. Dazu benutzt sie Methoden aus der Zugriffsschicht die rein funktional oder in der Datenbank gespeichert (stored procedures/ user defined functions) sein können.

Mit dieser Architektur ist es völlig egal, ob die Datenbank relational, mongo oder monkey heißt.

D*B

[camouflage]

... am Thema vorbei, setzen 5!

Alles Ansichtssache lieber Dieter.

Wenn schon Best Practices verlangt werden, ist nebst Python, Java oder JSON die Frage nach der DB und deren Handling legitim. Ist halt meine Meinung.

Kann dir auch ein gutes Handbuch dazu empfehlen oder belege mal einen Kurs (learn.mongodb.com, ist free) bei denen - hat noch nie geschadet.

[Fuerchau]

Nun, SQL (Structured Query Language) ist also im Wesentlichen eine Abfragesprache, was sie eben sehr effektiv auch kann.
Insert/Update/Delete hat sich da nicht wesentlich geändert, denn die Where-Klausel ist ja wieder ein Query.
Die Prozedursprache von SQL ist sehr dialektlastig, also DB-spezifisch, und reicht im entferntesten nicht an die Möglichkeiten einer Programmiersprache. Beim SQL-Server wird z.B. davon abgeraten größere Prozeduren zu schreiben, da diese die DB insgesamt belasten.
Bei der DB2 for i ist das auch nicht viel anders. Da werden C-Programme erzeugt, die von SQL-Engine aufgerufen wird.
Da ist es doch sinnvoller, das Programm direkt selber zu schreiben und statt SQL eben Prozedur-Aufrufe zu tätigen. Das ist wartbarer und zudem noch effektiver.
Die Implementation von "pSQL" ist sehr verschieden und die wenigsten machen da tatsächlich ausführbaren Code sonderen i.W. interpretierenden Code, also eine Zwischenschicht.
Dazu kommt dann, dass bei zu langer Ausführungszeit, die von verschiedenen Faktoren abhängt, schon Mal ein SQL-Timeout gemeldet wird. Bei einem Service-Programm ist mir das noch nie passiert.

Prozeduraufrufe aus dem Programm sind mit Einzelfeldern und Strukturen möglich und daher sehr effektiv. Strukturen werden gar nicht unterstützt und Arrays sind eigentlich eine Katastrophe.

Und da ja nun MongoDB bereits angesprochen wurde, dann lest dies hier mal:

https://www.mongodb.com/resources/pr...red-procedures

Zusammengefasst: Stored Procedure wird nicht unterstützt und Stored Functions nicht mehr empfohlen. Die wesentliche und nachvollziehbare Begründung ist, dass der Optimizer da keine Chance hat, Abfragen zu optimieren.

[BenderD]

Alles Ansichtssache lieber Dieter.

Wenn schon Best Practices verlangt werden, ist nebst Python, Java oder JSON die Frage nach der DB und deren Handling legitim. Ist halt meine Meinung.

Kann dir auch ein gutes Handbuch dazu empfehlen oder belege mal einen Kurs (learn.mongodb.com, ist free) bei denen - hat noch nie geschadet.

... vielleicht das falsche Forum erwischt? MongoDB auf AS/400 mit RPG - oder gibt es da Neuigkeiten?