Ok, da wenig Hoffnung besteht dass mal jemand in die Dokumentation schaut bereite ich jetzt diesem Ratespiel mal ein Ende:

http://www.hibernate.org/hib_docs/v3/re ... criminator

Ich entnehme Deinen Äusserungen, daß Du keine Lösung für das Problem kennst und Dich stattdessen auf eine meiner Ansicht nach arrogante Position zurückziehst, in dem due andere Personen als unqualifiziert und andere Lösungen als Hack bezeichnest.

Da in diesem Forum keine Antwort mehr zu erwarten ist, werde ich die Frage wohl im englischen Forum nochmals stellen müssen, in der Hoffnung das sich dort jemand unserer unwürdigen Probleme erbarmt.

Du weisst wie man sich Freunde macht, ehrlich.

Nein, ich reagiere nur empfindlich darauf wenn mir von jemandem der mein Problem Domain nicht kennt Unfähigkeit in Bezug auf Datenmodellierung vorgehalten wird. Wenn ich zudem nicht mal ansatzweise einen Hinweis auf die Abbildung in Hibernate bekomme, trägt das natürlich auch nicht gerade zu einer netteren Antwort bei.

Ich weiß Deine Bemühungen seht zu schätzen, allerdings habe ich den Eindruck, daß Du zum einen über alle Maßen überzeugt von der Leistungsfähigkeit von Hibernate bist, zum anderen dann aber bei einer Problemstellung, für die Du nicht sofort eine Lösung parat hast, den Fehler bei Deinem gegnüber suchst.

Ich evaluiere Hibernate jetzt schon seit zwei Wochen intensiv und mir gefallen die angebotenen Funktionalitäten sehr gut. In Bezug auf das Mapping zwischen vorhandenen Datenmodellen und einem z.B. nach den Kriterien von Martin Fowler entworfenen Domain Object Model tue ich mich jedoch sehr schwer, aus der vorhanden Dokumentation die Möglichkeiten des Frameworks zu erkennen und abzuschätzen.

Wie bereits ausführlich beschrieben können wir keine Subclasses einsetzen. Wenn wir die Funktionalität zur Vermeidung von Redundanz aufteilen wollen, bleibt uns nur der Ansatz der Komposition/Delegation, z.b. mit einer Klasse "Instrument", die Attribute der Klassen "InterestFlavour", "DividendFlavour", "OptionFlavour" o.ä. referenziert.

Soweit so gut besteht unser Hauptproblem jedoch darin, daß das derzeitige und leider unveränderliche Datenmodell i.ü.S. nur "Instrument"+"InterestFlavour" oder "Instrument"+"DividendFlavour" als jeweils eigenständige Entität kennt.

Während wir für neue Instrumente, die wir in einer neuen Struktur abbilden, natürlich kein Problem haben (diese Stelle in der Doku mit den drei erwähten Varianten haben wir natürlich bereits verprobt) , bleibt unser Problem mit der Ansteuerung der "alten" tabellen leider bestehen.

Deswegen natürlich die Frage, ob es als "Notlösung" z.B. möglich ist, für das Mapping eigene SQL-Statements zu verwenden?

Wie bereits ausführlich beschrieben können wir keine Subclasses einsetzen. Wenn wir die Funktionalität zur Vermeidung von Redundanz aufteilen wollen, bleibt uns nur der Ansatz der Komposition/Delegation, z.b. mit einer Klasse "Instrument", die Attribute der Klassen "InterestFlavour", "DividendFlavour", "OptionFlavour" o.ä. referenziert.

Soweit so gut besteht unser Hauptproblem jedoch darin, daß das derzeitige und leider unveränderliche Datenmodell i.ü.S. nur "Instrument"+"InterestFlavour" oder "Instrument"+"DividendFlavour" als jeweils eigenständige Entität kennt.

Während wir für neue Instrumente, die wir in einer neuen Struktur abbilden, natürlich kein Problem haben (diese Stelle in der Doku mit den drei erwähten Varianten haben wir natürlich bereits verprobt) , bleibt unser Problem mit der Ansteuerung der "alten" tabellen leider bestehen.

Deswegen natürlich die Frage, ob es als "Notlösung" z.B. möglich ist, für das Mapping eigene SQL-Statements zu verwenden?