hi,

i want to create an employee ID in such a way that the ID itself gives me enough info about that employee. my present scenario is this:
"80 cities grouped into 8 zones, 185 products grouped into 10 product groups, 700 strong salesforce. everymonth, 25-30 leave and more or less join. what kind of code should i create, i.e. the structure of code? i dont seem to get a solution for this?
at present i am using something like this "NY TGR 14/90" for an employee called Mr. ABC. where NY is city name(New York); TGR is his product group name, 14/90 means his number is 14 out of all 90 TGR group members in the country.
If anyone could advise a more better code structure, i would really appreciate it. my database depends on this ID, n i have designed all other things properly. just need to get this sorted out. hoping for you guys to respond soon, Regards

i wouldn't even think of doing this

just have an autonumber ID

keep all the other info in separate fields - if some are dependent on others - eg salesman allocated to a territory, which is in a region - then only store the teritory in the employee record, as the region can be determined from the territory.

then you can contenate these separate fields for presentation in any way you want - or easily select salesforce in a certain area etc etc

Insane to say the least. It will degrade to a complete and utter chaotic meltdown.

I have never seen a complex coding system work. The number of permutations increases by the square of every new idea you add to it.
Processes are made possible by reducing the number of connections between concepts.
If that gibberish wasn’t good enough for you; listen to the Husky. He has it right.

I will add my support to the previous answers.

You have a database to track the information about the employee. Why make a complex code system to identify some arbitrary part of that information?

Absolutely definitely do not use a complex string containing special characters as the Employee table primary key. Just use a number.

I agree with all the other contributors.

Consider what you would do if an employee moves to another area. That would mean you'd have to create a new ID and copy all the personal records across to the new ID then delete the old one. This is not how data is supposed to be managed.

The elements you mention should be stored as fields in the employee record. So you can still have a coded reference like the one you menion by using a query to generate the string on demand. This can then be shown on forms/reports. But this should definately not be used as the employee ID (key). In this situation, if an employee moves, then it is a simple matter of updating the relevant field and any reports/forms will show the correct reference.

hth
Chris

thanx for ur replies guys,
dear husky, can u give an example to elaborate your point. it'll help me visualise better what u have suggested.