When reading through the Hibernate documentation I keep seeing references to the concept of a "natural identifier". Does this just mean the id an entity has due to the nature of the data it holds? IE: A user's name+password+age+something are its identity?
+3
A:
What naturally identifies an entity. For example, my email address.
However, a long variable length string is not an ideal key, so you may want to define a surrogate id
AKA Natural key in relational design
gbn
2009-12-15 20:40:28
+1
A:
A social security number might be a natural identity, or as you've said a hash of the User's information. The alternative is a surrogate key, for example a Guid/UID.
Chris S
2009-12-15 20:40:32
The hash (and it doesn't need to be a hash since a key can be multi-column) would only be a valid natural key if the data cannot change (e-mail is fine, name is iffy, password is unlikely and age is wrong).
Tordek
2009-12-15 20:42:31
@Chris S: Not opposite: "surrogate"
gbn
2009-12-15 20:44:29
@Tordek: good point. @Gbn Updated the text a little. The wikipedia articles actually have good explanations of both
Chris S
2009-12-16 11:55:28
+3
A:
A natural identifier is something that is used in the real world as an identifier. An example is a social security number, or a passport number.
It is usually a bad idea to use natural identifiers as keys in a persistence layer because a) they can be changed outside of your control, and b) they can end up not being unique due to a mistake elsewhere, and then your data model can't handle it so your application blows up.
Mark Byers
2009-12-15 20:42:00
One hopes that the key is constrained, eg primary key constraint to reduce such risks
gbn
2009-12-15 20:46:46
You can constrain it in your data model, but you can't constrain real-life - mistakes do happen, and your data model doesn't need to break when they do. If you need to correct someone's SSN because for example it was entered incorrectly, it should be a single UPDATE. If you've used it as a key throughout your system... serialized it, stored it in backups, and possibly even sent it to external systems, you're completely screwed. There's no way you are going to be able to update that person's SSN without breaking something. PS: don't store SSNs at all unless you have to.
Mark Byers
2009-12-15 20:59:07
True, it still needs constrained and there should be a difference between logical model and implementation. SSN aint unique either... http://www.computerworld.com/s/article/300161/Not_So_Unique
gbn
2009-12-16 05:47:00