Re: [hibernate-dev] mutable versus immutable natural keys

On Wed, Dec 7, 2011 at 6:08 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: One of the use cases way back when I tried using Natural Keys was for accessing user accounts indexed by phone number. So 90% of our data access pattern was just mapping a phone number to a primary key, loading that entity, and the rest of the data would be cached... Phone numbers are interesting as they are considered immutable, but in the U.S. we infrequently have area code splits. There's also (fairly rare) cases where people update their phone number, say, if they move cities. Or, a phone number may be dropped and then later reused by an entirely different user. Maybe the user can expect some disruption in service but the expectation is service is available minutes after porting is done. There's also many issues dealing with various identities such as device ID or subscriber IDs. For example MIN versus MSISDN versus MDN. In all cases for a carrier we would store one of these values and then build an index with the others. The index is basically a table as such: class NumberMapping { @Id long id; String number; int type; // usually an enum Subscriber sub; } So you would select data using two columns "String, int" (not one). It would be nice to have NaturalKey be composite, if possible...Maybe declared as above? Or it might make sense to simply do like you do for composite @Id. @NaturalId class PhoneNumber { @Column String number; @Column int type; } @Immutable class NumberMapping { @Id long id; @NaturalId PhoneNumber number; @ManyToOne Subscriber sub; } The above is sort of venturing off-topic but maybe compound keys need to be discussed as well.