Неправильная постановка задачи. Когдв вяжуться две таблицы, покрайней мере у одной из них,поле должно быть первичным ключем. Если у обеих таблиц эти поля первичные ключи,
тогда заводиться специальная связная таблица, которая реализует связь многие-ко-многим.
В принципе, использование поля типа char, в качестве первичного ключа - дурной тон,
обычно как следствие непродуманного перехода с dbf формата.
Правильнее запись в таблице идентифицировать с помощью двоичного ID, который и использовать для организации связи. Ну и при необходимости его и IDENTITY можно
сделать.

Genady

По поводу dbf, использование сурогатных ключей идет оттуда. Решительно нет
никакой причины, при использовании SQL технологии к их использованию.
Это менее эффективно, например при кластеризации индекса он будет занимать
большее место. Кроме того это идеологически неправильно. В свое время мне пришлось разгребать, последствия такого непродуманнго шага. В таблице контрагентов
был принят первияный ключ char(4), после того, как оказалось, что 9999 значений мало, ситуация стала тупиковой. Если бы использовался ID, и таким
образом физический и логический ключ были разделены, то этой бы проблеммы просто не возникло. Я бы расматривал этот атрибут как пользовательский номер,
и задал бы ему размер чуть побольше, и в сущности мне было всеравно, какую
семантику вкладывали в структуру этого ключа пользователи. Скажем по таблице
договоров было приянто именно такое решение, пользовательский номер договора был объявлен как varchar(16) и за полгода 3 раза менял структуру, размер и
семантику, что практически никак не сказалось на БД. Кореекировалось через
один update.

Насчет знаменитого ID, ну да, это оно и есть. Юмор у меня такой. И написано
было в контексте разговора, мне забавным показалось, что ID воспринялось как
некая внутрисистемная возможность.

Извиняюсь, (причем дико),произошла путаница в терминалогии. Мне термин "суррогатный ключ" не нравиться, я под ним понимал другое.
Давайте, что бы быть точнее я изложу терминологию к которой я привык.

Физический ключ - это ключевое поле, которое однозначно идентифицирует запись в таблице, т.е. это primary key.

Логический ключ - это атрибут с помощью которого осуществляется
прикладная идентификация моделируемого объекта.

Например моделируется объект "Договор", и есть такая прикладная идентификация договора как "Номер договора" (кстати прикладная идентификация не обязательно
уникальна, и возможно несколько систем прикладной идентификации для того, или
иного прикладного объекта. Например входной и выходной номер документа.

В принципе понятие договор может моделироваться несколькими таблицами, и это
правильно, ну например как последствие нормализации. Схема такая, любой
моделируемый объект мы идентифицируем физическим ключем ID, который есть двоичное
число (не обязательно целое, могут быть и урезанные варианты). Его можно сделать
Identity, хотя я не сторонник этого. Такие ключи, логично применять в журналах
прикладной аудитентификации.
Этот ID есть внутри системная фишка, посягать на которую прикладники не могут, через нее мы вяжем прикладные объекты. Для пользовательской идентификации существуют логические ключи, их можно делать char, они могут иметь сложную структуру, разбиты на зоны, их можно индексировать, они не обязательно уникальны,
их может быть несколько. Это и есть разделение физического ключа, на который мы возлагаем функции обеспечения целосности и физической идентификации. И логического
ключа, на который мы возлагаем задачу прикладной идентификации и все.
Насчет dbf, это моя старая головная боль, извиняюсь, что выплескнул. Совсем
недавний пример - делают таблице пользователей, в качестве первичного ключа -
используют его login. И в журналы его пихают, естественно. Ну не зная я почему
фоксисты так делают. Может быть и dbf здесь не причем, но исключения попадаются
крайне редко. Как только бывший dbf-ник начинает проектировать базу данных, так и понеслось.

иметь внутреннюю структуру, быть инддексированны

Genady
Вспомнил я эту дискуссию по поводу суррогатных и интелектуальных ключей.
Ну не нравится мне термины суррогатный и интелектуальный ключ. По моему они суть
дела затеняют. Получается что суррогатный, это какой то не настоящий, плохой, а
интелектуальный он ого го, крутой в общем. Мне кажется термины логический и
физический ключ более точно отражают существо дела. Во всяком случае исчезает
противопоставление этих механизмлв.