GORM und Vererbung

Grails’ object relational mapping (GORM) basiert auf Hibernate, bietet aber leider (noch) nicht alle mapping – Möglichkeiten, so auch bei der Vererbung.
Grundsätzlich gibt es 3 Möglichkeiten, Vererbung in Hibernate zu mappen:

  • table per class hierarchy
  • table per subclass
  • table per concrete class

Bei der mapping Strategie table per class gibt es genau eine Tabelle für alle Klassen, die von der Vererbung betroffen sind. Zusätzlich gibt es eine sog. discriminator Spalte als Meta-Information, um welche Klasse es sich konkret handelt. Diese Strategie hat den Nachteil, dass die Tabelle sehr viele Spalten haben wird, nämlich die Gesamtzahl aller Spalten aller beteiligten Klassen zzgl. der discriminator-Spalte. Viele dieser Spalten werden null-Werte enthalten (dürfen als keinen not-null Constraint besitzen), wenn sie nämlich kein Attribut der gemappten Klasse sind. Für einen DB-Designer ist dieser Entwurf nicht zu gebrauchen.

table per subclass erstellt für jede Klasse in der Vererbungshierarchie eine Tabelle, allerdings für die Subklassen nur mit hinzugekommenen Attributen. Um die notwendigen Daten aus der DB wieder auszulesen, müssen die Tabellen daher gejoint werden, was Performance kostet. Gerade bei einer größeren Hierarchie kann dies deutlich spürbar sein (> 2 Tabellen) und führte bei einem Kunden auf einem älteren DB-Rechner dazu, dass die Ausgabe > 10 Sekunden brauchte.

Auf Grund der Nachteile bei den o.g. Strategien eignen sich beide nicht für produktive Anwendungen, erst recht nicht für diejenigen, die für eine hohe Benutzerzahl ausgelegt sind. Aber es gibt noch eine dritte Strategie, table per concrete class. Diese Strategie erstellt nun für jede Subklasse eine eigene Tabelle, mit all ihren Attributen (auch den geerbten). Für das Auslesen der Daten aus der DB sind dann auch keine joins mehr nötig. Sowohl aus Performance-Sicht, als auch für den DB-Designer ist dies die richtige Wahl.

Und hier offenbart sich aber das Problem mit Grails: die Strategie table per concrete class wird als einzige Strategie von Grails nicht unterstützt. Standardmäßig nutzt Grails die sog. table-per-hierarchy (hier: table per class) Strategie. Alternativ lässt sich table per subclass verwenden:

Dies empfinde ich als einen deutlichen Nachteil von Grails und hoffe, dass in einer der nächsten Versionen auch die dritte Strategie implementiert wird. Ein entsprechendes Jira-Ticket existiert bereits. Je mehr Entwickler die Implementierung wünschen, um so schneller wird sie auch realisiert. Daher wäre es wünschenswert, wenn mehr für dieses Feature voten.

Links:

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">