Подход для изменения Первичного ключа от GUID до BigInt в связанных таблицах SQL Server
У меня есть две таблицы с 10-20 миллионами строк, которые имеют первичные ключи GUID и в leat 12 таблиц, связанных через внешний ключ. Базовые таблицы имеют 10-20 индексов каждый.
Мы перемещаемся от GUID до первичных ключей BigInt. Я задаюсь вопросом, есть ли у кого-либо какие-либо предложения на подходе. Прямо сейчас это - подход, который я обдумываю:
- Отбросьте все индексы и fkeys на всех включенных таблицах.
- Добавьте столбец 'NewPrimaryKey' к каждой таблице
- Сделайте ключевые идентификационные данные на этих двух базовых таблицах
- Напишите сценарий таблицы x обновления "изменения данных, установите NewPrimaryKey = y где OldPrimaryKey = z
- Переименуйте исходный primarykey к 'oldprimarykey'
- Переименуйте столбец 'NewPrimaryKey' 'PrimaryKey'
- Сценарий назад все индексы и fkeys
Это походит на хороший подход? Кто-либо знает об инструменте или сценарии, который помог бы с этим?
TD: Отредактированный на дополнительную информацию. Посмотрите это сообщение в блоге, которое обращается к подходу, когда GUID является Основным устройством: http://www.sqlmag.com/blogs/sql-server-questions-answered/sql-server-questions-answered/tabid/1977/entryid/12749/Default.aspx
3 ответа
Конечно, похоже, что эта стратегия будет работать - отмена ограничений, изменение колонки из-под них (тип меняется, имя остается прежним), а затем воссоздание ограничений довольно элегантно.
Цель состоит в том, чтобы в конечном итоге отказаться от столбцов GUID? Если да, то вы не сможете вернуть место, пока таблицы не будут скопированы или перестроены, поэтому можно сделать следующую корректировку:
...
4.Сценарий изменения данных "update table x, set NewPrimaryKey = y where OldPrimaryKey = z
5. Сбросить исходный первичный ключ до 'oldprimarykey'
6.Переименуйте столбец 'NewPrimaryKey' в 'PrimaryKey'
.
7.Создайте все индексы и fkeys (построение кластерных индексов "перестраивает" таблицы)
8.Для всех таблиц, не имеющих кластерных индексов, сделайте что-нибудь, чтобы убедиться, что они будут перестроены и их пространство будет восстановлено (например, постройте и затем отбросьте кластерный индекс)
Само собой разумеется, протестируйте это на dev box перед запуском на Production!
Я бы также добавил:
Перед запуском убедитесь, что у вас есть хорошая текущая резервная копия. Измените сервер для работы в однопользовательском режиме (сначала уведомите пользователей о периоде отключения). Вы не хотите, чтобы пользователи пытались вводить данные, пока это происходит.
Ваш подход таков, как я бы это сделал .
Вам действительно нужен bigint? обычный 4-байтовый int будет равен 2 миллиардам (2 147 483 647).