I've read the documentation of hibernate. And I found this that made me confused until now.

--------------------------------------------
Chapter 25. Best Practices

...
Declare identifier properties on persistent classes.

Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. We recommend that identifiers be 'synthetic' (generated, with no business meaning).

Identify natural keys.

Identify natural keys for all entities, and map them using <natural-id>. Implement equals() and hashCode() to compare the properties that make up the natural key.
...
---------------------------------------------

My question are:

0. Related with the first practice, do I have to (for the sake to follow the best practices) define synthetic identifier, even if my entity already has it's own identifier. For example in entity Employee. Employee already has it's own identifier that is employeeNumber that follow the business rule of the company.

1. May I know the reasons in "There are all sorts of reasons..." stated in the text.

2. In 3 layered application (data, business, presentation layer), do I need to create both deleteEmployeeById(Long employeeId), deleteEmployeeByNumber(String employeeNumber), getEmployeeById(Long employeeId) and getEmployeeByNumber(String employeeNumber) in service layer class instead of create all of them but deleteEmployeeByNumber(String employeeNumber) since I can delete by employee id after I get the the object by calling getEmployeeByNumber(String employeeNumber)?

This problem really burden me, because I want clean codes that provide access to an object by (one identifier if possible, wether it is syntetic or ). I really appreciate if you could give me some good reference to create good design application.

Thanks for your reply

Some questions to help you make the best decision:

1. do you define the employeeID as the primary key for at least one table? If not you may consider using a synthetic ID.
2. is it a numeric value or string? you get a (small) performance boost by joining on numeric keys. If you think you may need all the perf (huge tables) you may want to join on numeric fields.
3. if an employee's status changes (last name change, move to a diff location) do you have data that needs to stay associated with the old record?

Marius

they make relationships alot easier to handle if you just have a primary key by itself that doesn't mean anything.




Only if you want to run a bulk delete with all the processing done on the database. But if you have an object in memory and are manipulating it, you can just call the regular hibernate methods; save, update, delete on the object and hibernate handles the sql invisble to you using whatever the database needs as the primary key. Your object can have whatever it wants to be used in the equals method.

I have many entities that will have relationship with employee entity. Therefore I need to decide how to uniquely identify employee. I'm confused what to choose: synthetic ID or company-defined ID. If It is suggested that I use synthetic ID, then I will save company-defined ID as unique property of employee entity and let another entity (of course by default in hibernate) identify employee by its synthetic ID.

The problem is, should I use synthetic ID?



The ID is alphanumeric (e.g. 40188200687X). Other entities are not aware of how the ID is formed. They only care how to uniquely call an entity of employee (just like common use of relationship in hibernate).



Yup, But in the case of the employee hasn't had any relationship to other entities yet, I can delete the object. If it has, I may not delete it. Instead I just need to set status of the employee as 'off'.