My colleague read that natural keys should be avoided and created an entity model like this:

The domain model requires the natural_key to be unique, it has a real world equivalent. Every time I access an object a query to the database is issued, just to find the object in the cache. That makes the cache less attractive. I would assume that if I use the natural_key as identifier the database roundtrip is avoidable if the object is in the cache. This should improve performance significantly.

Is there any reason why not using the natural_key as the object identifier?

Thanks
Haug

Search the forum on that subject. There is also a good link somewhere, but I can't find it.
Then choose the best for your project

I found one statement from Christian Bauer (christian@hibernate.org) in a discussion about composite keys.

"Experience has shown that natural keys almost always cause problems in the long run. A good primary key must be unique, constant, and required (never null or unknown). Very few entity attributes satisfy these requirements, and some that do are not efficiently indexable by SQL databases. You should be absolutely sure that a candidate key attribute never changes through the data's entire lifetime before promoting it a primary key.

For these reasons, we strongly recommend that new applications use synthetic identifiers (also called surrogate keys). Surrogate keys have no business meaning - they are unique values generated by the database or application. There are a number of well-known approaches to surrogate key generation."

If these requirements are met I would not use a synthetic key no matter if the field has a buisiness meaning or not. Synthetic keys are a performance hit in this situation. It would be interesting to know what problems natural keys caused as Christian mentioned.

Haug

The requirements are mentioned in that paragraph, in bold. The list of problems is therefore:

- unique: A natural key has, by definion, semantics outside of the database. How do you guarantee unique values? Is there a single entity/generator? Will it be the same trustable entity for as long as the data lifes?

- constant: As the natural key has semantics in the "real world", will these semantics be constant? Can you guarantee that existing values never change?

- required: Thats easy.

If you don't use existing (natural) candidate key attributes of your business entities and use a surrogate key, you immediately avoid all these issues. The attribute will then be just a normal attribute, maybe with unique values, but it has no relevance for entity identification.

There are many discussions about this issue on the web, just search with Google.