Как лучше однократно объединить несколько БД в одну?
Есть несколько БД, расположенных в различных региональных филиалах, с одинаковой структурой. Самая крупная и использующая максимум функциональности - московская БД, в остальных объемы данных меньше, и не все возможности (в связке с программой-клиентом) используются.
Встала задача объединения всех региональных БД на базе московской и переноса на выделенный сервер (MS SQL Server 2012 Standart Edition), с последующей работой с системой только через него.
Проблема миграции заключается в том, что в качестве первичных ключей используются интежеровские счётчики и, соответственно, ключи таблиц уникальны только в пределах одной БД. База достаточно большая - много связанных таблиц и хранимых процедур, плюс клиентское приложение.
Интересует, какие существуют возможные варианты решений для подобного рода задач.
UPDATE
Всем спасибо за советы.
Понравилась идея с изменением внешних ключей на "on update cascade". Нашёл и доработал скрипт, генерирующий SQL-код сначала для удаления, затем для создания заново констрейтов (с сохранением параметров и заменой только on update) с последующим их чеком. Но в процессе тестирования выяснилось, что в случае нескольких внешних ключей между двумя таблицами (например, UserCreatorID, UserEditorID) все, кроме первого fk, должны быть no action. И к сожалению, таких случаев довольно много.
Переход на GUID'ы посчитан нецелесообразным, так как придётся дорабатывать ещё и клиентские приложения.
Сейчас решаем, работать ли с разными диапазонами ключей, или их регенерировать с использованием вспомогательных полей. Но так как встала другая срочная задача, вопрос миграции на единый сервер отложен на некоторое время.
Я бы предпочел повозиться с числовыми индексами (зафиксировать в большой базе и поменять значения ключей в маленькой, потом объединить), чтобы все было "ровно". Но я сдвинутый на всю голову перфеционист :-)
Проще всего сделать рядом GUID-ы (или новый числовой счетчик) и обновить связи (кодом).
Алексей Немиро: похоже так и придётся действовать: для всей схемы БД вычислить последовательность переливки записей, добавить во все таблицы поле "код сервера" и "статус/дата обработки", потом регенирировать ключи через связку с кодом сервера в вычисленной последовательности. Когда все клиенты будут переключены на единый сервер, удалить вспомогательные поля.
Понравилась идея с изменением внешних ключей на "on update cascade". Нашёл и доработал скрипт, генерирующий SQL-код сначала для удаления, затем для создания заново констрейтов (с сохранением параметров и заменой только on update) с последующим их чеком. Но в процессе тестирования выяснилось, что в случае нескольких внешних ключей между двумя таблицами (например, UserCreatorID, UserEditorID) все, кроме первого fk, должны быть no action. И к сожалению, таких случаев довольно много.
Сейчас решаем, работать ли с разными диапазонами ключей, или их регенерировать, с использованием вспомогательных полей. Но так как встала другая срочная задача, этот вопрос отложен на некоторое время.
На мой взгляд, ваш путь только через миграцию всех таблиц БД в промежуточные с переходом на id типа guid и дальнейшую смену первичного ключа. Работа большая, но других вариантов не вижу.