aspose file tools*
The moose likes Object Relational Mapping and the fly likes Two PKs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Two PKs" Watch "Two PKs" New topic
Author

Two PKs

Sujan Pradhan
Greenhorn

Joined: Jul 19, 2006
Posts: 11
I've been puzzled as to how Hibernate treats two PKs. In the documentation it seems one of the two keys is chosen at random as an ID.

Could someone please shed some light into what are the scenarios behind choosing one over the other or some other technique?
Saeed Amer
Ranch Hand

Joined: Jan 20, 2004
Posts: 135
I am not a hibernate guru but I know Relational DBs very well and no table can have more than one Primary Key (it could be a composite PK of course). Could you please point me to where you read in documenation about Hibernate supporting two PKs?

Regards,
pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547
there can be several UNIQUE keys. only a unique key is a candidate for THE ONLY PRIMARY KEY.

so i'm not sure what you are referring to... can you give more infos ?


pascal
nirumagics
Greenhorn

Joined: Jul 21, 2006
Posts: 15
Hibernate uses only one primary key for a Table..In mapping it hold's Forignkey along with primary key. Nothing more then that. If it is in documentation send me the Url.
Sujan Pradhan
Greenhorn

Joined: Jul 19, 2006
Posts: 11
My apologies for the late reply.

I think I gave the wrong notion about the hibernate's use of PK in that I thought hibernate randomly picked a key (from two keys which happened to be a composite key). However, it turns out that in this case the key was a surrogate key and therefore no need to have a composite key.

All of you were right in the sense that if the candidate for a PK happens to be a compsite key, the mapping would follow with something like this:




I also get the feeling that hibernate wants every table to have a surrogate key (which is much easier to work with) rather than composite keys (hibernate refers to this only when legacy schema is in the picture).

For example, let's say I have two FKs which make up a composite PK. Would it be a good practice to have auto-generated surrogate keys for this table or leave it as it is? My perception is the former simply b/c it serves the purpose of uniquely identifying a record without complications (it could get worse if the composite PK contained more than two keys for example). Any thoughts?
Arun Kumarr
Ranch Hand

Joined: May 16, 2005
Posts: 513

For example, let's say I have two FKs which make up a composite PK. Would it be a good practice to have auto-generated surrogate keys for this table or leave it as it is? My perception is the former simply b/c it serves the purpose of uniquely identifying a record without complications (it could get worse if the composite PK contained more than two keys for example). Any thoughts?


Yes. Keys are basically used for,

1. Easy searching
2. Unique identification
3. Having a constraint while inserting a row into a particular table.

However primary keys(If we take surrogate, here) doesnt really bother what goes inside other columns. Your DB design is done in such a way, that you don't mind who the caller of the table is, who is going to do insert,update or delete rows from the tables. You see to that your DB design has absolutely all mappings correct, that no wrong data is inserted.

You cannot assume your Front end model to take care of all relations and insert only correct data. Consider a Link table, where a parent,child relation is maintained. If you have a composite primary key on <parent, child> you can be for sure that there is never an entry with just an entry in parent. if you prefer a surrogate key, of course, you can have an unique key, but they can sometime take null. Again you can make the column refering to child 'not null'. But that is where the classic composite keys do the work.
[ August 06, 2006: Message edited by: Arun Kumarr ]

If you are not laughing at yourself, then you just didn't get the joke.
pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547

If you have a composite primary key on <parent, child> you can be for sure that there is never an entry with just an entry in parent. if you prefer a surrogate key, of course, you can have an unique key, but they can sometime take null. Again you can make the column refering to child 'not null'. But that is where the classic composite keys do the work.


i would definetely prefer a surrogate key over a composite key. mark the other two cols as "unique" and not null.
it is easier to search, update, delete manually and hibernate (and other tools) prefer non-composite keys.

pascal
Arun Kumarr
Ranch Hand

Joined: May 16, 2005
Posts: 513

Certainly surrogate keys are always discussed as an alternative to composite keys.
Take a look at this link http://www.bcarter.com/intsurr1.htm

The take away is that you can never say that surrogate keys always do effectively replace the need of a composite-key. There is so much data modeling gray matter to be applied before designing a table with any of these keys.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Two PKs
 
Similar Threads
Farscape: The Peacekeeper Wars
How to get auto generated primary key from a CMP?
table-per-subclass conceptual issue
Simple but Confusing .
Best way to generate PK in EJB