• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Two PKs

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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,
 
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 662
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
pascal betz
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 662
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
A feeble attempt to tell you about our stuff that makes us money
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic