Umsetzungen in Java vs. Umsetzungen auf Datenbankebene

[RolandTi]

Tag zusammen !

ich bin neu in eurem Forum und brauche einmal etwas Argumentationsinput von euch. Die konkrete Frage lautet: Warum sollte man mit Java programmieren / Aufgaben lösen, wenn man bspw. auf Datenbankebene alles schneller / performanter durch SQL, das DBMS und dessen über Jahre aufgebauten und optimierten technologischen Stack umsetzen könnte?

Bitte versteht mich nicht falsch, ich selbst programiere sehr gerne in Java und mache auch gerne datenbankseitige Entwicklung mit SQL und teilweise auf PL/SQL und TSQL. Beim Lösen macher Aufgaben komme ich momentan in meinem Programmierumfeld mit Personen in Kontakt, die Umsetzmöglichkeiten in Java bzw. die Performance von Java stark verachten und lieber alles direkt in der Datenbankebene mit SQL oder den entsprechenden Erweiterungen der jeweiligen Datenbank (MS SQL Server: T-SQL, Oracle: PL/SQL) umsetzen. Hier benötige ich etwas Argumentationsinput für die Javawelt. Einige Beispiele meinerseits wären Strukturierbarkeit, Aufteilungsmöglichkeiten, Testbarkeit, Abstraktionsmöglichkeiten, vernünftige Wachstums- und Erweiterungsmöglichkeiten der Softwareprojekte.

Was gerne von dem von mir erwähnten Klientel in meinem Programmierumfeld angebracht wird, sind die Umsetzungsmöglichkeiten und angeblich unterirdische Performance mit JPA gerade in Bezug auf Verarbeitung größerer Datenmengen. Auch hier wird von dem von mir erwähnten Klientel lieber direkt mit SQL Optionen gearbeitet.

Besten Dank für eure Beteiligungen.

Grüße
Roland

 

[LimDul]

Ui, spannendes Thema - ich habe jahrelang in Oracle PL/SQL mit Oracle Forms entwickelt - kenne daher beide Seiten.

Also, ein wichtigen Spruch, den man kennen sollte: "premature performance optimization is the root of all evil". Von vornerein zu diskutieren ob A oder B performanter ist, ohne es zu messen ist in den meisten Fällen ähnlich sinnvoll, wie darüber zu diskutieren ob Stoff- oder Ledersitze in einem Auto besser für den Verbrauch sind.

Wobei ich da aber bei dem Schnitt zwischen DB und Java persönlich folgendes sagen:
* JPA versteckt den Datenbankzugriff so gut, dass ein Java-Entwickler leicht Code produzieren kann, der in Java gut aussieht, aber viel zu viele bzw. zu inperformante Queries zur Folge hat. Da muss man schon aufpassen.

Eine Datenbank ist besonders gut darin mittels SELECT performant Daten zu finden. Dies ist etwas, das kann sie (aufgrund der Tatsache, dass intelligente Index- und Datenstrukturen hat) normalerweise deutlich besser, als wenn man erst alle Daten in Java lädt und dann dort sucht. Da geht es aber rein um die Selects, da spielt PL/SQL und Co erst mal keine Rolle.

Sobald es um die fachliche Verarbeitung von Daten geht (Also wir in den Bereich PL/SQL gehen), verschwinden die Performance Vorteil massiv.

Das heißt, an der Stelle würde ich an deiner Stelle überlegen, ob du anregen willst, mal einen Proof of Conecpt für einen kleinen, klar definireten Teil zu machen wo man mal die Performance misst und gegenüber stellt. Denn neben Performance spielen ja auch weitere Themen eine Rolle:

* Wartung: Wer soll die Software warten? Wo sieht die Firma ihre Zukunft? Will man immer für Weiterentwicklungen immer PL/SQL und Java Entwickler vorhalten, die gesamten Prozess überblicken?
* Continues Integration: Wie integriert sich PL/SQL darein?
* Tests: Wie integriert sich PL/SQL darein?
* Wo wird der PL/SQL Code verwaltet?
* Wie erfolgt das Deployment?

 

[httpdigest]

Dem kann man eigentlich nichts mehr hinzufügen. Ein Punkt zu Wartung, der mir allerdings noch einfällt, der aber schon unter "Wer soll die Software warten? Wo sieht die Firma ihre Zukunft?" subsummiert werden kann ist: Was ist mit Migration auf ein neues Datenbankmanagementsystem? Es kommt ja nicht selten vor, dass z.B. Firmen von Oracle DB weg hinzu PostgreSQL wechseln. Will ich dann 100 Dialekt-spezifische PL/SQL mit Datenbankspezifischen Funktionen migrieren? Das habe ich mal drei Monate lang gemacht.

 

[White_Fox]

Also ich finde ja, man sollte generell ein Werkzeug nicht benutzen, wenn man ein anderes hat das zum Lösen des konkrete Problem geeigneter ist.

 

[LimDul]

Ach mir fällt noch ein kleiner Punkt ein. Entwicklungsgeschwindigkeit/Lokale Testbarkeit. Wir entwickeln sehr viel, dass wir lokal gegen eine H2 Datenbank entwickeln, während in Produktion bzw. auf den Testsystem Oracle läuft. Das hat den Vorteil, dass der Entwicklungsprozess relativ leichtgewichtig ist (sofern man bei einem JBoss von leichtgewichtig sprechen mag). Setzt man auf PL/SQL Komponenten, braucht man entweder:
- Eine lokale Oracle Datenbank mit den entsprechenden Features (Kostet die eigentlich?) oder immer Zugriff auf eine zentrale Oracle Datenbank (=stabiles Netz) wo jeder Entwickler mindestens ein privates Schema hat.

 

[httpdigest]

Also ich finde ja, man sollte generell ein Werkzeug nicht benutzen, wenn man ein anderes hat das zum Lösen des konkrete Problem geeigneter ist.

Sehe ich auch so, nur ist das Problem ja, dass die Metrik "geeignet" nicht so einfach zu beantworten ist, bzw. von sehr vielen Faktoren (einige auch von strategischer Natur) abhängt, die @LimDul alle schon aufgezählt hat. Performance der Lösung ist nur einer von sehr vielen Faktoren.

 

[White_Fox]

Naja, ich lese das so daß jemand den Versuch wagen will, eine historisch gewachsene Firmenstruktur aufzubrechen. Wenn jemand hier in einem Forum nach Argumenten für sein Vorhaben fragt, dann heißt das erstmal, daß dort kein Schmerz herrscht der zu einer Änderung nötigt.

Ergo: Die gewählte Lösung mag aus unserer Sicht absolut nicht optimal, und die vorgeschobenen Argumente grober Unfug sein. Aber offenkundig will der Rest des Teams das nicht ändern.

Aber offenbar hat der TS selber keine oder nur schwache Ideen, warum Java besser wäre. (Falls es das ist, ich kenne mich mit Datenbanken nun gar nicht aus.)

Und das hier:

Warum sollte man mit Java programmieren / Aufgaben lösen, wenn man bspw. auf Datenbankebene alles schneller / performanter durch SQL, das DBMS und dessen über Jahre aufgebauten und optimierten technologischen Stack umsetzen könnte?

Ich würde stark vermuten, daß die Firma überhaupt nicht mehr in der Lage wäre ihr Vorgehen zu ändern. Selbst wenn es einige wollen würden.

 

[fhoffmann]

Ergo: Die gewählte Lösung mag aus unserer Sicht absolut nicht optimal, und die vorgeschobenen Argumente grober Unfug sein. Aber offenkundig will der Rest des Teams das nicht ändern.

Wenn der "Rest des Teams" sich hervorragend mit Datenbankprogrammierung (wie PL/SQL) auskennt (aber keine Ahnung von Java hat), muss es keine dumme Entscheidung sein, bei der alten Technologie zu bleiben. Was würde nämlich passieren, wenn der einzige Java-Programmierer der Firma krank wird (oder auch nur in Urlaub fährt).

 

[LimDul]

Die ganzen Argumente, die ich gebracht habe, sind ja im Endeffekt ergebnisoffene Fragen. Zwar schneidet in der Regel im Vakuum Java besser ab, aber das muss im Einzelfall nicht der Fall sein. Auch für plsql gibt es ja z.B. Unit-Test Frameworks (utplsql), man kann sich eine CI Infrastruktur auch dafür aufgebaut haben etc.

Allerdings ist Datenbank erst mal rein Backend - irgendwo kommt in der Regel noch ein Frontend dazu. Und zumindest Oracle Forms ist - als ich es das letzte mal gesehen habe - alles, aber nicht mehr Zeitgemäß. Und spätestens dann hat man vermutlich einen Technologiebruch.

 

[White_Fox]

Die ganzen Argumente, die ich gebracht habe, sind ja im Endeffekt ergebnisoffene Fragen.

Wie gesagt, mein Beitrag war keinesfalls kritisch dir gegenüber gemeint. Ich hab deinen Beitrag (genaugenommen gar keinen Beitrag) gelesen, als ich meinen Post abgeschickt habe, da war der Thread bei mir noch jungräulich.

Ich wollte vielmehr die Intention des TS etwas hinterfragen.