-->
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.  [ 3 posts ] 
Author Message
 Post subject: Critical decision on usage of composite keys
PostPosted: Thu Aug 24, 2006 4:01 am 
Newbie

Joined: Thu Nov 04, 2004 3:08 am
Posts: 5
Location: United Kingdom
Hi,

We are using hibernate during the design of our project.

As the current database model stands, it appears that if natural keys are used as primary keys it would make querying easier.In addition we plan to denormalise some data as we wish to avoid complex joins and reduce time execution of the query.

The problem is we need to make a decision on usage of composite keys in a table, as due to the use of natural keys , most tables will need to have a composite key.

We need to know in hibernate what are the pros and mostly cons of using composite keys.

There are 2 approaches in our mind.

1. Use the hibernate composite keys as recommended, ie.

<composite-key>
<key-many-to-one id=address class=address lazy=true>
<composite-key>

Here we wish to avoid a join on address table.how do we achieve this, as we understand lazy will not query address table howver if we call getkey it will then load the address table along with other keys which form part of the composite key at a later point too.
We want to avoid this too, can we avoid it, as we always need to call getkey

2. Use hibernate composite keys in a workaround manner.

In order to ensure that hibernate does not fire a join, define composite keys as
<composite-key>
<key-many-to-one id=address column=address>
<composite-key>

i.e use as a regular key without mapping to parent table to avoid the join.
However here we dont seem to be maintaining relationships.

The third approach is defining a composite class, however whatever i do, i need a solution where preferrably can define relationships in the composite key but still avoid costly joins.

Could you please tell me the best approach from design point of view and problems with hibernate composite keys.

THIS IS URGENT , PLEASE HELP

Thanks
Vivek


Top
 Profile  
 
 Post subject: correction in question
PostPosted: Thu Aug 24, 2006 4:28 am 
Newbie

Joined: Thu Nov 04, 2004 3:08 am
Posts: 5
Location: United Kingdom
Sorry in approach 2 should have been

Use hibernate composite keys in a workaround manner.

In order to ensure that hibernate does not fire a join, define composite keys as
<composite-key>
<key-property id=address column=address>
<composite-key>

i.e use as a regular key without mapping to parent table to avoid the join.

I got a response from chris , it appears will have to take this on a case by case basis, where i need data will have to define relationship , else regular property.

Please add more information to help me make my decision better.


Top
 Profile  
 
 Post subject: more questions about performance
PostPosted: Thu Aug 24, 2006 5:16 am 
Newbie

Joined: Thu Nov 04, 2004 3:08 am
Posts: 5
Location: United Kingdom
I would like to know if the usage of composite keys causes any performance overhead specifically with respect to the way hibernate handles composite keys.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 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.