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 ist es nicht aussagekräftiger, weil die meisten gespeicherten Prozedurensprachen vom Design her schlecht sind. Aber es wird wahrscheinlich schneller laufen als in einer externen Anwendung.

Ich schätze, es kommt darauf an, wie vertraut Sie mit PL/SQL sind, wie viel Zeit Sie haben, um das zu schreiben, wie wichtig die Leistung ist und ob Sie vernünftigerweise erwarten können, dass die Wartungsmitarbeiter mit PL/SQL vertraut genug sind, um ein großes, in PL/SQL geschriebenes Programm zu warten.

Wenn die Geschwindigkeit keine Rolle spielt und die Wartungsmitarbeiter wahrscheinlich keine PL/SQL-Kenntnisse haben, ist es vielleicht besser, eine "traditionelle" Sprache zu verwenden.

Sie könnten auch einen hybriden Ansatz verwenden, bei dem Sie PL/SQL verwenden, um Zwischendaten zu generieren (z. B. Tabellen-Joins und Summen oder was auch immer) und eine separate Anwendung, um den Fluss zu kontrollieren und Werte und Fehler zu überprüfen.