Вот-вот. Я только хотел посоветовать оформить эти изменения в письменном виде отдельной бумажкой, но меня опередили.
Составьте доп. соглашение к договору, что в случае несогласованных изменений, внесенных в ваш продукт со стороны заказчика, вы не несете ответственности, а все убытки ложатся на его счет. На основании этого доп. соглашения составляете протокол в их присутствии, в котором конкретно пишите, что делается, и с чем вы, как разработчик, категорически не согласны.

Для общего развития: а вы пробовали узнать мотивацию их действий? Может все-таки это имеет какие-то основания?

[quot ant[Ares]]
Они утверждают, что потом сами будут как-то использовать данную БД в своих целях. И почему то им взбрело в голову, что запросы к таблицам с ключами будут выглядеть сложнее чем без них. Не заставлять же мне их учить SQL. Тем более, что это бесполезно...[/quot]

Все равно несколько странно. А вы не спросили, почему они считают, что запросы будут сложнее? Я бы не смог удержаться, чтобе не задать этот вопрос. Вдруг мне сейчас будет откровение.
Заставлять никого не надо, но причину (настоящую) знать не мешает. Кстати, а какая там у вас БД?

antAres
Есть список "подразделений", у каждого есть внутренний номер. И они хотят чтобы этот внутренний номер был "как бы" первичным ключом, но чтобы он генерировался не БД, а вводился вручную и при этом не проверялся... т. е. возможно дублирование. Вот пример объяснения: Как же мы сможем узнать список сотрудников подразделения если в таблице сотрудников есть указатель на подразделение которого мы не знаем (т.к. он генерируется автоинкрементно).
Т.е. они хотят делать там:
SELECT * FROM Workers WHERE idDepartment = "их вручную введеный код"
И на мой пример что можно сделать так:
SELECT * FROM Wokers WHERE idDepartment in (SELECT idDepartment FROM Department WHERE DepartmentCode = "их долбаный код") они говорят что это сложнее, что они нифига не въезжают в этот дибильный запрос, что мы нихера не понимаем в проектировании, а им потом с этим работать


Уже интереснее. Ну сразу им вопрос. Если номер будет вводиться вручную, то возможны повторы. Т.е. за этим надо следить либо ручками, либо в автомате, но это усложняет логику.
Мне кажется, что из второй части следует то, что они просто не знают, как вставлять новые записи, если заранее неизвестен код записи в мастер-таблице. Т.е. их подход может иметь место, но в данном случае он просто кривее.
Хотя тут есть еще один нюанс. Я вот подумал, подумал и придумал. Я так понимаю, что программа имеет отношение либо к кадрам, либо к какому-то учёту работников. Тогда может иметь место ситуация, что этот самый код подразделения присваивается сначала НА БУМАГЕ (руководителем или ОК) по каким-то их бизнес-алгоритмам, от которых они не хотят отступать. Вполне естественная ситуация, особенно для гос. конторы. Тогда ваш автоинкремент действительно худшее решение, а программеры защищают интересы организации.
Пусть пользователь вашей программы (или формирующий решение) сам следит по своему талмуду за актуальностью кодов подразделений вообще и для каждого сотрудника в отдельности. Тогда можно автоинкремент на фиг убрать. Таким образом, оператор при вводе нового сотрудника получает бумажку, в которой уже имеется код подразделения, в которое надо зачислить работника. Он его тупо набирает с клавиатуры и работник попадает в свое подразделение. Ну а дальше именно что обычный select без всяких там пирамид с in'ами.
И в конце действительно возникает вопрос: а причем тут все-таки ключ? Особенно если подразделений не больше 20-30 и путаться в них никто не собирается?