Есть записи по пользователям. В зависимости от группы планирую подгружать данные из соответствующих таблиц.
Теперь о проблеме. Программа раньше использовалась в учреждении где USE_ID в таблице USERS был первичным ключом, который заполняли табельным номером. У нас же в организации в этом деле просто хаос. Табельный номер может меняться периодически. Плюс новому человеку могут дать табельный номер уволенного человека. Т.е. однозначности нету.
Поэтому вынес табельный номер в отдельное поле.
Далее, необходимо делать синхронизацию по пользователям, с ERP системой Парус. Т.е. человек нажал на кнопку и загрузил пользователей из Паруса, для того что-бы можно было не тратить время на ручное добавление. Вот тут возникает дилемма.
В программе есть ручной ввод пользователей. Но тут получается что человек вбил пользователя вручную, и нажал на кнопку Синхронизации. А в базе есть другой пользователь, с таким-же табельным, но другим Ф.И.О.
Как выходить из этой ситуации?

Dimitry Sibiryakov, если бы всё было так просто. На данный момент в организации 500 человек.
С "двойниками" уже встречался:(

Dimitry SibiryakovHopkroftС "двойниками" уже встречался:(
Добавь в идентифицирующие поля дату рождения. Обычно этого хватает.

Я рассматривал этот вариант. Но получается что мне нужно добавить в первичный ключ, Ф.И.О. и дату рождения. Т.к. на USE_ID очень много завязано(хранимки, записи в других таблицах).
Вот и хочу довести эту программу для нашей организации с её безобразиями.

Dimitry Sibiryakov, за вашу практику хоть раз встречался случай когда Ф.И.О. и год рождения были одинаковы у двух разных людей?

mad_nazgul Никак, в общем случае задача не решается.
Хорошо, нужно добавить, возможность от "порчи" данных.
1. А если при экспорте добавить, фишку, когда мы встречаем пользователя, с имеющимся, табельным номером, то программа
предложит обновить по нему данные. Т.е. загрузить ту информацию которая содержится в базе.
2. Добавить поле, приёма на работу и увольнения. Таким образом безболезненно могут существовать 2 человека с одинаковыми табельными номерами.
Поле, USE_ID, сделать автоинкрементном. (На него очень много завязано.)

mad_nazgul, а вот мне интересна следующая ситуация, имевшая место быть в нашей организации.
Человек уволился, а потом его опять приняли на работу. Т.е. в идеале, нужно сделать таблицу, пользователи ->табельные номера.
Где табельные номера включают поля,

USER_ID ,
ID -идентификатор табеля,
DATE_BEG -дата выдачи,
DATE_END - дата окончания,
REASON - причина окончания(изменение штатного, уволили и т.д.)) - возможно связать по внешнему ключу с таблицей значений.

Не внесёт ли это избыточность?

P.S. эту идеологию подсмотрел в Парусе.

mad_nazgul,
Я правильно понял ситуацию, что таблица будет примерно следующей:

К примеру таблица Reason выглядет следующей.
REASON
id, caption
. . .
2, Смена табельного номера
3, Увольнение по собственному желанию

USER_ID, ID, DATE_BEG, DATE_END, REASON
123, 12, 12.05.2012, 11.06.2012, 23 - новая должность к примеру
123, 15, 12.06.2012, 15.01.2013, 3 - уволился
123, 25, 12.12.2014, NULL, NULL - был опять принят на работу

Тогда есть несколько вопросов:
1. для определения табельного номера человека нужно просто найти в таблице последнюю запись по нему?
2. при приёме в отделе кадров, программа долна их оповестить что данный человек уже есть, и ему достаточно присвоить новый табельный?
3. А может ли быть, в один день у человека 2 табельных номера? Допустим когда переводят его.

mad_nazgulЯ бы кончено ввел сущность "Приказ", где бы вводились приказы по человеку и его перемещения.
Еще можно тупо сделать как в форме Т1.
Спасибо, за совет. Мысль хорошая, буду в эту сторону смотреть.

mad_nazgulСчитать человека новым сотрудником или старым...
. . .
Если нет, то заводится новая личная карточка.
Вот за эту мысль огромное спасибо! Я что-то эту ситуацию упустил из виду.

Alexander2, ну они у себя в Парусе присваивают им какие-то левые табельные, что-бы они с новыми не пересекались. А мне голову ломать как это всё совместить:)