SQL Server повторно использует один и тот же идентификатор IDENTITY дважды

Question

Надеюсь, вопрос не слишком общий.

У меня есть таблица Person, в которой есть столбец PK Identity Id.

Через C # я вставляю новые записи для Person и для 3 добавленных идентификаторов установлено значение 1,2,3.

Также с помощью C # я выполняю все удаления лиц с Id = 1,2,3, чтобы вТаблица больше.

После этого я запускаю несколько сценариев изменений (я не могу опубликовать их, так как они слишком длинные) также на Персоне таблицы.

Я не выполняю никаких СБРОСОВ.

Теперь самое интересное:

Если я позвоню SELECT IDENT_CURRENT('Person'), вместо 3 появится 3 *.

Если я снова вставлю Person, я получу Person с идентификатором3 добавлено вместо Id 4.

Есть идеи, почему и как это может произойти?

РЕДАКТИРОВАТЬ

Я думаю, что нашел объяснение моего вопроса:

Во время выполнения изменений БД через SQL Server Management Studio конструктор создает временную таблицу Tmp_Person и перемещает данные из Person в нее.После этого он выполняет переименование Tmp_Person в Person.Поскольку это новая таблица, индекс начинается заново с самого начала.

Answer 1

Свойство IDENTITY не гарантирует уникальность. Вот для чего PRIMARY KEY или UNIQUE INDEX. Это описано в документации в разделе замечаний вместе с другими предполагаемыми действиями. CREATE TABLE (Transact-SQL) IDENTITY (Свойство) - Примечания :

Свойство identity в столбце не гарантирует следующее:

• Уникальность значения - уникальность должна обеспечиваться с помощью ограничения PRIMARY KEY или UNIQUE или индекса UNIQUE.

• Последовательные значения в транзакции - транзакция, вставляющая несколько строк, не гарантирует получение последовательных значений для строк потому что другие параллельные вставки могут произойти на столе. Если значения должен быть последовательным, тогда транзакция должна использовать эксклюзивную блокировку на столе или используйте СЕРИАЛИЗИРУЕМЫЙ уровень изоляции.

• Последовательные значения после перезапуска сервера или других сбоев -SQL сервер может кэшировать значения идентификаторов по соображениям производительности и некоторые из назначенные значения могут быть потеряны во время сбоя базы данных или сервера запустить снова. Это может привести к пробелам в значении идентичности при вставке. Если пробелы не приемлемы, тогда приложение должно использовать свой собственный механизм генерации ключевых значений. Использование генератора последовательности с Опция NOCACHE может ограничить разрывы для транзакций, которые никогда совершено.

• Повторное использование значений - Для данного свойства идентификатора с определенным начальным значением / приращением значения идентификатора не используются механизмом повторно. Если конкретный оператор вставки завершается неудачно или если оператор вставки свернут тогда потребленные значения идентичности теряются и не будут генерируется снова. Это может привести к пробелам, когда последующая идентичность значения генерируются.

Эти ограничения являются частью дизайна для улучшения производительность, и потому что они приемлемы во многих общих ситуации. Если вы не можете использовать значения идентичности из-за этих ограничения, создать отдельную таблицу, содержащую текущее значение и управлять доступом к таблице и назначением номера с помощью применение.

Подчеркните мой вопрос.