[linux-l] Was mich an WebApplikationen immer und?immerwiderAnkotzt...

Rocco Rutte pdmef at gmx.net
Sa Aug 2 12:29:49 CEST 2008


Hi,

* Olaf Radicke wrote:
>Vorweg: Ich habe mir Hibernate nur theoretisch angeschaut.

>Klar, als Programmierer würde ich auch gerne den SQL-Code raus haben, aber die 
>ganzen Stärken einer relationale DB verbaue ich mir damit. So weit ich 
>gesehen und verstanden habe, ist nicht nur das ökonomische Speichern ein 
>Problem, sondern auch das selektieren. 

>Das extrahieren von Datensetzen aus der Datenbank über komplexe Unterabfragen 
>mit Beziehungen über mehreren Relationen hinweg scheint mir schwer - wenn 
>nicht sogar - unmöglich, jedenfalls nicht ökonomisch. 

Jein, für Hibernate konkret gibt es HQL sowie auch programmatische 
Möglichkeiten, um programmatisch die Query zu bauen. Warum sollte man 
ORM benutzen wenn man am viel Ende weniger Funktionalität hat (z.B. das 
komplexe Abfragen gar nicht mehr gehen)?

>Konkretes Beispiel:

>Suche alle Autos mit dem Baujahr zwischen 2001 und 2005 ohne das Jahr 2004, 
>dessen Besitzer in einem Haushalt mit mehr als 4 Personen leben. Von dem 
>Ergebnis will ich pro Datensatz alle Werkstattage summiert haben, die das 
>Fahrzeug in Reparatur war, wegen des Fensterheber auf der Fahrerseite. Prüfe 
>ob das Fahrzeug seine Erstzulassung in einem Land mit Linksverker hatte und 
>nehme die andere Seite. Verwerfe alle Ergebnisse die auf mehr als 
>365Tage/Jahr kommen.

Das könnte in Hibernate auch nur so schwer sein wie die Query in SQL mit 
der Hand zu schreiben.

Der Punkt an ORM ist ja gerade, dass die Mapper über Introspection 
selbst wissen, was wie gejoint werden kann und muss bei einer Query. Für 
den ersten Teil mit den Autos z.B. hast du eine Klasse Car mit den 
Members owner und year sowie eine Klasse Owner mit Member persons. Query 
ist dann sowas wie:

   car.year between 2001 and 2005 and car.owner.persons > 4

ORM macht dann automatisch den Rest und zwar so, wie es für die 
jeweilige DB am besten ist (in Grenzen). Beim Refactoring kann sowas zum 
Beispiel wichtig sein, weil man sich um LEFT oder RIGHT JOINS statt 
INNER JOIN keine Gedanken machen muss, weil das aus der 
Object-Definition für ORM ableitbar ist; mit händischem SQL braucht man 
gute Tests, um in solchen Fällen keine Queries zu übersehen, die evtl. 
angepasst werden müssen.

>Hibernate wird das _irgendwie_ können. Aber das Ergebnis wird der Benutzer 
>nicht mehr abwarten, weil der glaubt, das Programm hätte sich aufgehängt. 
>(Mit Ausnahme fielleicht von Entwicklern die Eclipse-IDE benutzen. Die sind 
>waren gewohnt.)

Warum? Wie kommst du zu der Behauptung wenn du dir Hibernate nur 
theoretisch angesehen hast?

Sicher, Hibernate ist langsamer als handmade SQL, ist dafür aber in 
Punkto Entwicklungszeit beim Schreiben/Refactoring unschlagbar im 
Vergleich zu handmade.

MfG, Rocco



Mehr Informationen über die Mailingliste linux-l