Если это MSSQL то там на связях с нужной таблицей можно задать CASCADE UPDATE, но обязательно на всех связях таблицы. Тогда просто меняешь ID в исходной таблице, а дальше само поменяется. Но это самое плохое решение из всех возможных.

По-хорошему ID менять не надо, т.к. на то он и абстрактный ключ чтобы не нести никакой смысловой нагрузки. Не надо в него вкладывать смысл "ID справочника из другого источника", надо просто добавить поле "ID справочника из другого источника" и в нем меняй.

WiskyИзменения PK не моя пререгатива. Но то что сортировка по ID совпадает с VALUE наверное удобно, если эта сортировка требуется постоянно, а VALUE длинное. Изменение происходит крайне редко. Например справочник стран.
ИМХО увольнять надо за такое.
WiskyНа текущий момент я рассматриваю такой вариант.
Сформировать временную таблицу или коллекцию id_new, id_old,name_new, status ("новая", "измена","без измен") отсортированную по name_new . Для записей "верно" id_new заполнено. Проверяю последовательно записи в статусе "Измена" на условие id_old between id_new_l and id_new_r. Если верно то id_new=id_old иначе оставить пустым. Затем проставляю пустые id_new.
В процессе замены учти такую ситуацию:
т.е. поменяв ID с 2 на 5 ты не сможешь понять где новые 5, а где старые.

AkinaMasterZivПравило №2. Первичный ключ не несёт в себе никакой информации, никакой смысловой нагрузки в предметной области, он служит только для одной цели -- идентификации записи.Синтетический первичный ключ - да. Естественный - нет. Составной - всяко бывает...
ИМХО это в теории так, а в реальности только первое используется.

В остальном ТС честно сознался почему так
WiskyЗначение ID прорежено, т.к. ожидалась потребность редко вставлять значения. Сверху падает новая версия словаря, которая сопоставляется с текущей по CODE. Надо обеспечить, что после обновления sort by ID и sort by VALUE будут совпадать, при этом нужно минимизировать количество замен ID, т.к. на них ссылается таблица с полмиллиардом записей.
При проектировании перестарались с оптимизаторством, теперь пришло время наступить на эти грабли.

AkinaCane Cat FisherПравило № 4. Естественных первичных ключей не бывает.
СНИЛС. ИНН. ISBN. Номер страхового полиса. И т.д., и т.п. - примеров естественных первичных ключей дохрена.
ИМХО лучше не рисковать.
Одному знакомому уже третий ИНН выдали. Налоговая что-то у себя накосячила, приходит он за возмещением НДФЛ по ипотеке, а ему - у вас ИНН другой, и так несколько раз )))