Что вы делаете, когда ваш первичный ключ переполняется?

Question

У нас есть таблица с первичным ключом auto-increment int, максимальное значение которого теперь находится на пределе для типа T-SQL int.Когда мы пытаемся заново заполнить таблицу (поскольку в ключах имеются большие пробелы, и их недостаточно для ряда строк в качестве значения max int), он каким-то образом продолжает сбрасываться до значения max int.

Очевидно, это вызывает серьезные проблемы.PK никогда не должен был достигать этого значения, и изменение типа данных было бы большой задачей.Повторного заполнения должно быть достаточно, но оно не работает!

Как оно может продолжать сбрасываться?

Редактировать: чтобы прояснить ситуацию, этот запрос SELECT MIN(CategoryID), MAX(CategoryID) FROM dbo.tblCategories возвращает -2147483647, 2147483647 ..Это означает, что существуют фактические значения PK для минимального и максимального типа int.

Answer 1

Вы можете «повторно заполнить» таблицу, чтобы следующий назначенный столбец идентификаторов был меньше текущего максимального значения в таблице. Однако любой последующий DBCC CHECKIDENT сбросит внутренний счетчик до максимального значения, которое в данный момент находится в столбце. Возможно, отсюда и происходит сброс? И, конечно, в конце концов вставка достигнет двойного значения, что приведет к «Интересным временам» для команды поддержки производства.

По большому счету у вас проблемы. Я рекомендую создать одноразовый скрипт для удаления / сброса значений Uber-high ID. Обновление строк (и всех связанных значений внешнего ключа) - это один из вариантов, хотя это может потребовать отключения ограничений внешнего ключа, и я не знаю, что еще, поэтому я бы не рекомендовал это делать. Другой вариант - создать точные копии всех данных для элементов с высоким идентификатором, используя более прагматичные значения идентификатора, а затем удалить исходные записи. Это взлом, но это приведет к созданию гораздо более удобной базы данных.

Да, и отследите людей, которые помещают эти значения с высоким идентификатором, и - по крайней мере - отзовите их права доступа к базе данных.

Answer 2

Я был связан с проектом, в котором была похожая проблема - хотя в нашем случае кто-то выбрал поле с 4-значным номером в качестве первичного ключа, что вроде не сработало, когда мы приблизились к 9999 записям ...

В нашем случае мы создали новый столбец в таблице и заполнили его, изменили первичный ключ на этот столбец и переназначили все наши отношения с внешним ключом на новый ключ.

Очень грязно, но это сработало.

Answer 3

Создать новую таблицу с такой же структурой.Читайте от старого к новому (кроме ПК).Затем удалите старое и переименуйте новое.