Hibernate braucht für Joins zwischen Entitäten eine echte Foreign-Key Beziehung, was aber nicht immer vorhanden ist. Es ist einfach so, dass ein Datenbankmodell, welches vor ca 20 Jahren erstellt wurde und wegen irgendwelcher inkompatibilitäten zwischen verschiedenen Systemen hier und da "zurecht gebogen" werden muss. Natürlich kennen die DB-Designer die Normalformen, aber das lässt sich nicht immer so einfach umsetzen wie's auf der Hochschule gelerht wird ... Man kann darüber streiten ob es Unfähigkeit ist, aber Tatsache ist, dass Hibernate es nicht kann, die technische Möglichkeit aber besteht (und sogar wahrscheinlich recht einfach implementierbar ist). Hibernate ist in meinen Augen nicht fertig und wird zu unrecht in den Himmel gelobt.
PS: Nein, ich habe keine Lust Hibernate zu erweitern, da das Framework, was bei uns im Projekt verwendet wird eben tut und wir Hibernate nicht brauchen. Vielleicht wird Hibernate ja mal eine Alternative, da der Einsatz von freier Software schon verlockend ist.
Das Problem ist vermutlich eher, dass ebenfalls zwischen dem, was ein Entwickler und ein Kunde unter einem ordentlichen Datenbankmodell verstehen, Unterschiede bestehen können.
Für den Entwickler ist eine Entität eineindeutig durch einen zugehörigen Key repräsentiert, der Kunde möchte aber gerne nicht 1876430987 sehen, wenn er das Formular öffnet, sondern irgendwas "völlig schlüssiges", wie "WERNER_MEIER".
Das es einem dabei die Haare zu Berge stehen lässt, vor allem, wenn man auf Produkten anderer basiert, die sich dazu entschlossen haben, genau dies als Foreign Key zu deklarieren und dann daran denkt, welchen Aufwand man betreiben muss, um beim Neuanlegen einer Entität einen eineindeutigen Schlüssel sicherzustellen, ist nur allzu verständlich. Ich habe selbst oft genug vor diesem Problem gestanden. Da hilft dann nur ein ORM, dass einigermaßen flexibel damit umgehen kann.
PS: Nein, ich habe keine Lust Hibernate zu erweitern, da das Framework, was bei uns im Projekt verwendet wird eben tut und wir Hibernate nicht brauchen. Vielleicht wird Hibernate ja mal eine Alternative, da der Einsatz von freier Software schon verlockend ist.
Für den Entwickler ist eine Entität eineindeutig durch einen zugehörigen Key repräsentiert, der Kunde möchte aber gerne nicht 1876430987 sehen, wenn er das Formular öffnet, sondern irgendwas "völlig schlüssiges", wie "WERNER_MEIER".
Das es einem dabei die Haare zu Berge stehen lässt, vor allem, wenn man auf Produkten anderer basiert, die sich dazu entschlossen haben, genau dies als Foreign Key zu deklarieren und dann daran denkt, welchen Aufwand man betreiben muss, um beim Neuanlegen einer Entität einen eineindeutigen Schlüssel sicherzustellen, ist nur allzu verständlich. Ich habe selbst oft genug vor diesem Problem gestanden. Da hilft dann nur ein ORM, dass einigermaßen flexibel damit umgehen kann.
lg
Erik