This was the case: It was decided that two departments would be merged into one department. Consequently, all employees had to be merged into one dataset. (Each dataset handles the employees of a department.) Each employee is present in only one dataset. If an employee is transfered, then the data will be exported from the old department's dataset and imported into the new department's dataset. In the case of the big merge all employees had to be transfered to one dataset.

The problem with a meaningless ID would have been that many of those IDs would have occurred in BOTH datasets! They would have complicated the merge of the two datasets. A meaningfull primary key, like the employee ID, does not have this problem at all!

I was assigned the task to merge those datasets. The primary keys were allmost all meaningfull, like an employeenumber, a rostercode, and so on. This eased my job. Since that moment I no longer strongly advocate meaningless IDs.

Another, not entirely similar, example was rostercode. The attributes of a rostercode should be equal in both datasets. A rostercode from dataset A was imported only if that rostercode wasn't already present in B. This ensured that the rostercode occupied only one record. And only thanks to the fact that the meaningfull rostercode was also the foreign key, no additional replacements in other tables had to be done.

[snip]
>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.
>>
[snip]
>>
>>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.
>>