I think that's a reasonable assumption. The employee ID is the unique, single number that identifies the employee. If they design it such that the category is part of the ID and the category changes, then shouldn't the employee ID change and if it changes, shouldn't it be changed everywhere it was used as a foreign key in some other table? If the category can change without affecting anything, then the company is just saying that the employee ID is really just the part of the number after the dash. This would just be a poor design.

A surrogate PK is actually one of the things that data normalization depends on, so adding an ID field and using that to link records helps protect the integrity of the data if the company starts changing employee IDs (which, as I said before, is kind of dumb).

As for merging, I'm not sure why you feel it's hard. It depends, once again, on the data design. In the design I suggest, you have the ID field and the employee ID field. Are there dupes? Someone worked in both departments? You can tell by the employee ID field and the name fields? If there are no dupes of people, might there be dupes of the ID field? Perhaps. Then you do have a larger issue since you have to change some IDs and the cascade those into related tables.

The best design is going to be:

ID   Employeenumber    Category
1    12345             1
2    42535             2
3    34545             1
4    34534             1

>Okay, let's call it the employee-ID.
>
>You make here the assumption that all IDs will have to be changed if the category changes. But is this assumption correct? If the company would say "yes", then you'd have a decisive argument to call it a stupid decision. But again, is it possible that the company would say "no"?
>
>The behind-the-scenes, meaningless ID is not a prerequisite according to the normalization theory. There is also a real disadvantage to it. Have you ever tried to merge two databases of, for example, two groups of employees, let's say of two departments? This is not an easy job, but it is even harder if abstract IDs identify the employees, rather than an employee-ID.
>