Понравилась идея с изменением внешних ключей на "on update cascade". Нашёл и доработал скрипт, генерирующий SQL-код сначала для удаления, затем для создания заново констрейтов (с сохранением параметров и заменой только on update) с последующим их чеком. Но в процессе тестирования выяснилось, что в случае нескольких внешних ключей между двумя таблицами (например, UserCreatorID, UserEditorID) все, кроме первого fk, должны быть no action. И к сожалению, таких случаев довольно много.
Сейчас решаем, работать ли с разными диапазонами ключей, или их регенерировать, с использованием вспомогательных полей. Но так как встала другая срочная задача, этот вопрос отложен на некоторое время.
Алексей Немиро: похоже так и придётся действовать: для всей схемы БД вычислить последовательность переливки записей, добавить во все таблицы поле "код сервера" и "статус/дата обработки", потом регенирировать ключи через связку с кодом сервера в вычисленной последовательности. Когда все клиенты будут переключены на единый сервер, удалить вспомогательные поля.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.