Mike, you hit a good on here. One of the issues you need to consider is the
possible use of system generated vs. natural keys. For example, I could
have a DB model where the "uniqueness" of a person was determined by a
composite primary key of their employee ID and their company ID. However,
if the person moves between companies, this would change.
However, if you used a system generated key as the PK, then a change to the
PK (PK's must be unique but not all uniques need be PK's) is not required by
a re-assignment to another company.
Changes to PK's in an RDB are generally not good things for several reasons.
If, for example, you make the change to the PK, you really do the equivalent
of a "delete/insert" against the table when you commit your changes, not an
Update. This has some interesting implications for cached EB's, or even for
the traditional optimistic locking issues fo client/server. You are
creating an anomalous update condition for other users.
Not pretty, but it never is.
Andy
Andrew J. Roehr
Chief Technology Officer
Agillion Inc.
http://www.agillion.com
7600-B N. Capital of Texas Highway
Suite 220
Austin, TX. 78731
(w) (512) 682-8002
(f) (512) 306-7331
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
