Hi,

I am using a tightly integrated object inheritance model and I am concerned about what hibernate will do with the vast amount of data that I am likely to throw at it. For example, here is what my inheritance structure may look like:

entity > animal > mammal > feline > domestic cat
entity > animal > mammal > feline > wild cat
entity > animal > mammal > feline > big cat
entity > animal > mammal > cannine > domestic dog
entity > animal > mammal > cannine > wild dog
entity > animal > mammal > cannine > wolf
entity > animal > mammal > dolphine
entity > animal > mammal > human

The structure is much bigger with (potentially) thousands of classes inheriting from entity. Of each of these classes there could be potentially hundreds, thousands, millions of each type .. for ease lets assume there are 100 classes and there are 500 instances of each that are persisted.

What I dont want to end up in this case is a table containing the entity fields resulting a 50,000 record table - as this would grind the database when there are 500,000 instances of 100,000 classes - as opposed to each entity type having its own table (100 in total, each with the fields from all its parent classes).

When dealing with these scenarios I can only find options to either have subclasses merged into 1 table, or have 1 table for each class - which is what I want, but I dont want the fields split up!

eg: If cannine contains fields A, B and C, wild dog contains D and E ... then I create a wild dog, I want the wild dog table to contain A, B, C, D and E ... not just D and E split&join with A B C in cannine. (if that makes sense)

Ive thought about not telling Hibernate at all about the subclassing and to duplicate the fields in the .hbn.xml files - but would Hibernate care about there not being getter setters for them in the specified class (only in super classes). Im going to try this now.

Ideas as how I can broach this problem with Hibernate are welcome!

You can do that with the table-per-concrete-class approach. Note however that you will then get other problems with that approach. Take a look at [/url]http://www.hibernate.org/hib_docs/reference/html/inheritance.html[url]for the three possible approaches and their tradeoffs. Mapping such a huge inheritance hierarchy will not be an easy job in all cases.[/url]

Thanks for such a quick and helpful response!

I think the concrete class is the way I'll need to go inorder to distribute the load on the tables, otherwise there will be at least one table with the total number of rows of all instances of the base class and subclasses collected together.

All my objects that I persist are based off the root Entity .. and another problem arises when any Entity can be linked to any other Entity (so a Domestic Cat can be linked to a Human).

Currently I code this in my application by creating lookup tables with both the location of the data and the index (eg: linking from Human 3 to Cat 4 rather than having a HumanCat table with 3,4 in). This isnt possible to achive using join's in sql as I dont know what the table name is for the target data (in this case a cat).

Can you think of any ideas as to how I could use concrete classes and still be able to link by base class?

The limitations for associations are outlined in the document. Basically you can't do polymorphism on one-sides of associations when using table-per-concrete-class.

There is something wrong in model. I think you need to find something more "abstract", model with thousands of classes can be more useless than plain tuples.