-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: table per subClass (with discriminator) vs joined subClass
PostPosted: Fri Aug 05, 2005 5:56 pm 
Newbie

Joined: Mon Feb 09, 2004 11:14 am
Posts: 16
I queried for information regarding performance differences regarding the table per subClass (with discriminator) vs joined subClass, but did not find the information to help me. I am pretty sure that the table per subClass (with discriminator) is the better performer. Does anybody have any tests or experience to confirm my suspision.

Thanks.


sorry, previously posted in wrong forum.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 05, 2005 6:35 pm 
Regular
Regular

Joined: Thu Dec 02, 2004 7:11 am
Posts: 85
Actual perfomance is depends on many conditions: DB type, size of tables, presence of indexes, selectivites of descriminator column, type of queries and many others conditions....


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 05, 2005 6:53 pm 
Newbie

Joined: Mon Feb 09, 2004 11:14 am
Posts: 16
I agree, I guess I was thinking that a read on the database with the discriminator would be more efficient because the superClass would know the subClass and would create a better join clause that what would be created with the joined subClass.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 05, 2005 7:18 pm 
Regular
Regular

Joined: Thu Dec 02, 2004 7:11 am
Posts: 85
taa_sarge wrote:
I agree, I guess I was thinking that a read on the database with the discriminator would be more efficient because the superClass would know the subClass and would create a better join clause that what would be created with the joined subClass.


Not nessary. For example, if discriminator column have poor selectivity (many for one value, but seldom for another), then selectings for exact subclass may result bad perfomance due bad query plan generated. This is especially noticiable with Table per class hierarchy strategy.

I would recommend you to build prototype model for your data ant test for speed your queries. Because your data and your queries may significantly differs from ours. :-)


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.