Re: [JBoss-dev] fk in compound pk

[Andreas Schaefer]

Hi   Just a note regarding to a compound PK. Based on my experience as DBA I would suggest that you DO NOT use compound PK and use an artifical PK. You can still create an Index on you the fields of the original PK and keeping the values unique. The rational to do so is that values of the compound PK could change and you would have a hard time to adjust because the values must be unique. Imagine that you have a company with several offices. The office number is part of the compound key of the Orders. Now you have to close an office and transfer all the orders to one of the other offices. It will take a lot of time to renumber and adjust all the references from all FK. If you would use an artifical key then you would only have to renumber the values of the original PK attributes but not the references.   Have a nice day - Andy ----- Original Message ----- From: Dain Sundstrom To: 'Ken Chang' ; [EMAIL PROTECTED] Sent: Friday, November 09, 2001 1:13 PM Subject: RE: [JBoss-dev] fk in compound pk The problem has to do with the EJB spec.  The spec says that the pk must be set in the ejbCreate method and then can't be changed.  The spec also says that cmr fields can not be set until ejbPostCreate.  Furthermore the spec only allows cmp-fields in compound pks.  I haven't thought of a way around this yet. I'm considering supporting the mapping a cmp-field to the same column as a cmr-field, but this opens a big can of worms.  Most of the interesting database fk mappings are not supported in JBossCMP yet (like not null foreign keys).  When I rewrite the cmr code the first time (I always expect to write code 3 times) I plan on supporting the interesting fk mappings.   -dain -----Original Message----- From: Ken Chang [mailto:[EMAIL PROTECTED]] Sent: Friday, November 09, 2001 10:49 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] fk in compound pk this question bothers me for quite sometime now is it true that if i want to have fk in compound pk, i need to ditch the cmr field for the fk so no fk relationship can be maintained (e.g. even the fk does not exsist as a pk in coresponding table, and container managed cascade delete wont be possible too)? Ken