|
I am writing a web application using a legacy database where an inheritance relationship is represented using Table per subclass. Currently, there is the base class table, and over 70 tables that "inherit" from this base class, i.e. 70 subclasses.
If I map this situation via the Hibernate Table per subclass technique of using <joined-subclass>, then I will end up with polymorphic queries that have 70+ joins. Before I go and do all of this work, does anyone have any comment on what the performance of such queries would be like ? I realize that database performance is a very relative question, but in general I am asking whether queries with 70+ joins are even realistic ?
Alternatively, I was considering a mapping strategy where each of the 70 "subclasses" has two top-level class mappings:
1) a class mapped to the base class tables
2) a class mapped to the subclass-specific table
I would have a <one-to-one> association mapping between these using a primary key association so that when this "composite" object is saved, Hibernate will propagate the primary key generated for the base class table row to the primary key of the subclass table row (using generator="foreign")
One drawback of this alternative is that I would have to map the properties of the base class table over and over again for each subclass mapping (anyone know of a way around this ?). However, on the object side of things, I would have a convenience class with all of the base class properties,getters/setters and each subclass would just inherit from that, so I would not have to define the properties over and over again in the class defintions.
With this alternative I would not be able to do polymorphic queries, but the legacy database also has a discriminator column in the base class table, so I could do the equivlent of polymorphic queries.
Any comments on this approach vs. the <joined-subclass> approach, which is a more natural approach, but would result in polymorphic queries with 70 joins ?
|
Login
FAQ
Search
