Подход для изменения первичного ключа с GUID на BigInt в таблицах, связанных с SQL Server - PullRequest
Новая
       28

Подход для изменения первичного ключа с GUID на BigInt в таблицах, связанных с SQL Server

6 голосов
/ 28 апреля 2010

У меня есть две таблицы с 10-20 миллионами строк, которые имеют первичные ключи GUID и по меньшей мере 12 таблиц, связанных через внешний ключ. Базовые таблицы имеют 10-20 индексов каждая.

Мы переходим от GUID к первичным ключам BigInt. Мне интересно, есть ли у кого-нибудь предложения по подходу. Прямо сейчас я размышляю над этим подходом:

  1. Удалите все индексы и ключи на всех задействованных таблицах.
  2. Добавить столбец «NewPrimaryKey» в каждую таблицу
  3. Создайте ключ на двух базовых таблицах
  4. Скрипт изменения данных "обновить таблицу x, установить NewPrimaryKey = y, где OldPrimaryKey = z
  5. Переименуйте исходный первичный ключ в 'oldprimarykey'
  6. Переименование столбца «NewPrimaryKey» в «PrimaryKey»
  7. Сценарий обратно всех индексов и fkeys

Это кажется хорошим подходом? Кто-нибудь знает инструмент или сценарий, который поможет с этим?

TD: отредактировано для дополнительной информации. См. Этот пост в блоге, в котором рассматривается подход, когда GUID является основным: http://www.sqlmag.com/blogs/sql-server-questions-answered/sql-server-questions-answered/tabid/1977/entryid/12749/Default.aspx

Ответы [ 3 ]

3 голосов
/ 28 апреля 2010

Твой подход - как бы я это сделал.

Тебе действительно нужен бигинт? обычный 4-байтовый int будет равен 2 миллиардам (2 147 483 647).

int, bigint, smallint и tinyint

0 голосов
/ 28 апреля 2010

Я бы тоже добавил:

Убедитесь, что у вас есть хорошая текущая резервная копия перед началом. Измените сервер для работы в однопользовательском режиме (сначала оповестите пользователей о периоде простоя). Вы не хотите, чтобы пользователи пытались вводить данные, пока это происходит.

0 голосов
/ 28 апреля 2010

Похоже, что эта стратегия сработает: убрать ограничения, изменить столбец из-под них (изменения типа, имя останется прежним), а затем воссоздать ограничения довольно элегантно.

Является ли целью в конечном итоге отбросить столбцы GUID? Если это так, вы на самом деле не освободите пространство, если таблицы не будут скопированы или перестроены, поэтому, возможно, следующая настройка:

...
4. «Изменить данные», обновить таблицу x, установить NewPrimaryKey = y, где OldPrimaryKey = z
5. Отбросить исходный первичный ключ до 'oldprimarykey'
6. Переименуйте столбец «NewPrimaryKey» в «PrimaryKey»
7. Сценарий возврата всех индексов и fkeys (создание кластерных индексов «перестраивает» таблицы)
8. Для всех таблиц, которые не имеют кластеризованных индексов, сделайте что-нибудь, чтобы убедиться, что они восстановлены и их пространство восстановлено (такая сборка, а затем удаление кластеризованного индекса)

Само собой разумеется, протестируйте его на устройстве разработчика перед запуском в Production!

...