Ist es dumm, ein großes Stapelverarbeitungsprogramm komplett in PL/SQL zu schreiben?

Question

Ich beginne mit der Arbeit an einem Programm, das vielleicht am ehesten als eine Reihe von Berechnungen in Datenbanktabellen beschrieben werden kann und einmal im Monat ausgeführt wird. Die gesamte Eingabe erfolgt in Oracle-Datenbanktabellen, und die gesamte Ausgabe erfolgt in Oracle-Datenbanktabellen. Das Programm sollte über viele Jahre hinweg wartbar bleiben.

Es scheint einfach zu sein, dies als eine Reihe von gespeicherten Prozeduren zu implementieren, die jeweils eine sinnvolle Transformation durchführen, z. B. die Verteilung der Kosten auf die Abteilungen gemäß einigen Geschäftsregeln. Ich kann dann Unit-Tests schreiben, um zu prüfen, ob die Ausgabe der einzelnen Transformationen den Erwartungen entspricht.

Ist es eine schlechte Idee, dies alles in PL/SQL zu tun? Würden Sie schwere Stapelberechnungen lieber in einer typischen objektorientierten Programmiersprache wie C# durchführen? Ist es nicht aussagekräftiger, eine datenbankzentrierte Programmiersprache wie PL/SQL zu verwenden?

Answer 1

Normalerweise würde ich sagen, so wenig wie möglich in PL/SQL zu schreiben - es ist in der Regel viel weniger wartungsfreundlich - bei einem meiner letzten Jobs habe ich wirklich gesehen, wie chaotisch und schwierig es sein kann, damit zu arbeiten.

Da es sich jedoch um eine Stapelverarbeitung handelt und sowohl die Eingabe als auch die Ausgabe in der DB erfolgt, ist es sinnvoll, die Logik in PL/SQL zu speichern, um die Anzahl der "beweglichen Teile" zu minimieren. Wenn es sich jedoch um Geschäftslogik handelt - oder um Komponenten, die von anderen Teilen Ihres Systems verwendet werden - würde ich sagen, tun Sie es nicht

Answer 2

Ich habe eine große Anzahl von Stapelverarbeitungs- und Berichtserstellungsprogrammen sowohl in PL/SQL als auch in Pro C für ein Projekt. Sie zogen es im Allgemeinen vor, dass ich in PL/SQL schreibe, da ihre eigenen Entwickler, die das System in Zukunft pflegen würden, das einfacher zu verstehen fanden als Pro C-Code.

Letztendlich wurden nur die wirklich ausgefallenen Verarbeitungen oder Berichte in Pro*C geschrieben.

Es ist nicht notwendig, diese als gespeicherte Prozeduren zu schreiben, wie andere Leute angedeutet haben, sie können einfach Skriptdateien sein, die bei Bedarf ausgeführt werden, ähnlich wie ein Shell-Skript. Auch die Quellcode-Revisionskontrolle und die Migration zwischen Test- und Produktionssystemen wird dadurch erheblich erleichtert.

Answer 3

Solange die Berechnungen, die Sie durchführen müssen, angemessen UND lesbar in PL/SQL erfasst werden können, ist es am sinnvollsten, nur PL/SQL zu verwenden.

Der eigentliche Haken ist die Wartbarkeit - es ist sehr einfach, unwartbares SQL zu schreiben, und sei es nur, weil jedes RDBMS eine andere Syntax und einen anderen Funktionssatz hat, sobald man über einfaches SQL DML hinausgeht, und keine wirklichen Standards für Formatierung, Kommentierung usw.

Answer 4

Ich habe Batch-Programme mit C# und SQL erstellt.

Vorteile von C#:

• Sie verfügen über die gesamte Bibliothek von .NET und die ganze Leistungsfähigkeit einer OO Sprache.

Nachteile von C#:

• Batch-Programm und Datenbank getrennt - das heißt, Sie müssen Ihr Batch-Programm getrennt von der Datenbank verwalten.
• Sie müssen den ganzen verdammten SQL-Code löschen

Vorteile von SQL:

• Lässt sich gut mit dem DBMS integrieren. Wenn dieser Job nur die Datenbank manipuliert, wäre es sinnvoll, ihn in die Datenbank zu integrieren. Am Ende haben Sie eine einzige DB und alle ihre Komponenten in einem Paket.
• Sql-Code muss nicht entschlüsselt werden
• realistisch bleiben - Sie programmieren in Ihrem Problembereich

Nachteile von SQL:

• Es ist SQL und ich persönlich kenne es nicht so gut wie C#.

Im Allgemeinen würde ich wegen der oben genannten Vorteile bei der Verwendung von SQL bleiben.

Answer 5

Das ist eine schwierige Frage :) Es gibt einige Architekturen für die Datenbankprogrammierung, die Sie kennen sollten, und deren Kosten/Nutzen. 2 Tier bedeutet im Allgemeinen, dass ein Client eine Verbindung zu einer DB herstellt und direkte SQL-Aufrufe tätigt. 3 Tier bedeutet im Allgemeinen, dass Sie einen "Anwendungsserver" haben, der direkte SQL-Aufrufe an die DB ausführt, aber der Client spricht mit dem Anwendungsserver. Dies ermöglicht in der Regel eine "Skalierung nach außen". Schließlich gibt es noch 2 1/2-Tier-Anwendungen, die ein 2-Tier-ähnliches Format verwenden, nur dass die Arbeit in gespeicherten Prozeduren aufgeteilt ist.

Ihr Prozess hört sich nach einer Art "Back-Office" an, und die Kunden/Prozesse brauchen nur Ergebnisse, die einmal im Monat aggregiert und zwischengespeichert werden. Das heißt, es gibt keinen Agenten, der eine Verbindung herstellt, und zwar häufig, und sagt: "Führe diese Berechnungen durch". Stattdessen spielen Sie auf einen Prozess an, der hin und wieder stattfindet, und Sie kommen mit einer Nicht-Echtzeitlösung davon.

Angesichts dieser Anforderungen würde ich daher sagen, dass es im Allgemeinen schneller ist, näher an den Daten zu sein und SQL Server alle Berechnungen durchführen zu lassen. Ich denke, Sie werden feststellen, dass Ihnen die Nähe zu den Daten gute Dienste leisten wird.

Bei der Durchführung dieser Berechnungen werden Sie jedoch feststellen, dass einige Berechnungen nicht mit SQL-Servern durchgeführt werden können. Berechnen Sie zum Beispiel die aufgelaufenen Zinsen einer Anleihe oder eines anderen festverzinslichen Instruments. Das ist in SQL nicht sehr schön und eignet sich viel besser für eine reichhaltigere Programmiersprache. Wenn Sie jedoch nur einfache Durchschnittswerte und andere relativ vernünftige Aggregate haben, würde ich auf der SQL-Seite bei gespeicherten Prozeduren bleiben.

Also noch einmal, es gibt nicht genug Informationen über die Art Ihrer Berechnungen, oder was Ihr Haus in Bezug auf die SQL-Fähigkeiten der Entwickler für den Support vorschreibt, oder was Ihr Chef sagt... aber da ich mich mit SQL auskenne und gerne nahe an den Daten bleibe, würde ich für eine Aufgabe wie diese bei reinem SQL/Stored Procedures bleiben.

YMMV :)