Member 10028394 Ответов: 2

Почему первичный ключ SQL server пропускает номер

Я использую Sql Server 2012, и я создаю таблицу и сохраняю id в качестве первичного ключа, а также спецификацию идентификации "Да" для автоматического приращения 1.
но проблема в том, что номер пропуска таблицы
например, 1,2,3,4,5,6,7,8,9,10,11,12
и через некоторое время это пропущенное число и даст 101,102,103 и так далее
почему?

Что я уже пробовал:

Я использую Visual Studio 2013 для разработки веб-сайта

ZurdoDev

Вероятно, вы удалили записи.

PIEBALDconsult

Почему тебя это волнует? Идентификаторы сами по себе бессмысленны.

Member 10028394

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

CHill60

Вы можете найти Создание последовательности (Transact-SQL) | Microsoft Docs[^] полезный. Не считайте строки таблицы и не добавляйте 1 - Что делать, если два человека пытаются добавить запись одновременно? В конечном итоге вы получите дубликаты идентификаторов отгрузки, и это вызовет проблему. В реальном мире нет никаких требований к тому, чтобы идентификаторы отгрузки были последовательными. Если вы хотите, чтобы записи действительно имели последовательные номера, то вам нужно будет использовать последовательность, а также предотвратить удаление из таблицы (вместо этого отметьте записи как "не активные" или что-то в этом роде)

2 Ответов

Рейтинг:
4

Wendelius

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

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

Этот тип ключа обычно никогда не показывается пользователю, потому что он не имеет никакого другого значения, кроме предоставления значения ключа. Другими словами, это суррогат[^]

Member 10028394

Я хочу, чтобы ни одно число не пропущено (пропущено) ни в коем случае.
Любезно сказал мне, какой метод лучше
1) первичный ключ с автоматическим приращением
2) я подсчитываю строки таблицы и добавляю (один 1) и сохраняю это значение в первичном ключе вместо автоматического приращения

Wendelius

С помощью автоматического нумерованного поля вы не можете достичь ситуации, когда в нумерации не было бы дыры.

Как насчет удаления, что вы собираетесь делать, если запись будет удалена? Предположим, у вас есть строки 1, 2, 3 и 4. Затем номер 2 удаляется, что происходит?

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

Рейтинг:
2

RickZeeland

См. это обсуждение на StackOverflow: Приращение идентификатора скачет в базе данных SQL Server-переполнение стека[^]
и: Почему мой автоматически увеличенный идентификатор пропускает номера в SQL Server? - переполнение стека[^]

Member 10028394

Я хочу, чтобы ни одно число не пропущено (пропущено) ни в коем случае.
Любезно сказал мне, какой метод лучше
1) первичный ключ с автоматическим приращением
2) я подсчитываю строки таблицы и добавляю (один 1) и сохраняю это значение в первичном ключе вместо автоматического приращения

RickZeeland

Ни одному из них вы не можете доверять первичному ключу, вместо этого используйте другое поле.