ID Values
I always think about ID values as some buried part of the application whose value nobody should ever know or care about. The system I’m working on now is interesting because the employee IDs actually have meaning. The first few digits represent the state, the next few digits essentially represent an area, and the rest is unique to the employee.
I would normally think that this is unnecessary, that they could have just auto-generated a number and assigned it to an employee. But, out in the field, managers and support team members are able to help troubleshoot problems more quickly because of this. Somebody might call up their manager while they’re at the grocery store and ask why one of the employees can’t log into a particular system. After finding out the employee’s id number, the manager can quickly determine what state and region they are from, and where they should have access to.
This type of information-bearing ID can be very useful for quicker troubleshooting. But the ID value with business meaning doesn’t necessarily have to be the primary key on a database table. Hibernate.org recommends using ’synthetic’ (generated, with no business meaning) ID [meaning primary key] values. Could could still have a unique value in your database table that represented the user and still contained some sort of business value.