Почему SQL Server генерирует новое однозначное значение, даже если вставка не удалась? - PullRequest
0 голосов
/ 14 июня 2019

Запрос на создание таблицы с соответствующим полем, установленным как IDENTITY, следующий:

CREATE TABLE user (
    email varchar(100) primary key
    name varchar(30),
    pwd varchar(10) 
)

Измените таблицу, чтобы добавить поле IDENTITY:

ALTER TABLE user ADD id int /*NOT NULL*/ IDENTITY;

Поле email, равное PRIMARY KEY INDEX, не будет работать, если было установлено значение NULL или DUPLICATED, например предполагается, что myemail@domain.com уже существует, ОК, запрос не выполнен, но я изменил адрес электронной почты на anotheremail@domain.com SQL Server сгенерируйте новое значение для поля IDENTITY, основываясь на запросах, которые не были выполнены ранее. Мой вопрос: почему это происходит? (Это ТОЛЬКО на SQL Server или других провайдерах баз данных)

1 Ответ

4 голосов
/ 14 июня 2019

Что ж, это четко задокументировано в "CREATE TABLE (Transact-SQL) IDENTITY (Свойство)" :

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

Далее в документации также дается ответ на вопрос, почему, и предлагается, что делать, если это неприемлемо:

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...