@MaintstDev
Python | Vue

Почему ID не меняется?

Работаю с БД. Primary key = id.
Удалил несколько строк (всего было 3, осталась 1). Создал новую, но у неё ID уже 4, но по логике должен быть 2 (ибо была только 1 строка)

Правильное ли поведение бд? Как можно принудительно заставить БД ставить адекватные порядковые ID?
  • Вопрос задан
  • 98 просмотров
Решения вопроса 4
darakanoit
@darakanoit
Веб-разработчик
Правильное поведение
Значение автоинкремента продолжается,даже если предыдущие записи были удалены.
ALTER TABLE tbl AUTO_INCREMENT = 5; вроде это для изменения значения автоинкремента.
Ответ написан
@deliro
Агрессивное программирование
Это и есть адекватные. ID - уникальный идентификатор записи в таблице. Где же он будет уникальным, если двум разным записям может принадлежать один в разное время?
Ответ написан
@Hanneman
Billing and Value Added Services expert
Раз уж автор пишет, что "вопросы задаются в целях криворуких опытов, не более", то тогда напишу еще пару строк, чтобы "подтолкнуть" к практическому "почему это так".

Смотрите (не вдаваясь в технические особенности): вот у вас, допустим, количество обращений к базе исчисляется тысячей в секунду, и это всякие INSERT, UPDATE, DELETE, SELECT. Внутренняя реализация СУБД, как программного продукта, естественно рассчитана на такую нагрузку и в ней заложены правила, как оптимально с этим всем справляться. Вряд ли движок БД будет оптимально работать в режиме чистого FIFO (First In - First Out), т.е. "живой очереди", когда каждый следующий запрос будет обрабатываться как только закончится обработка предыдущего, верно? Именно тогда, после обработки каждого DELETE, БД будет "знать", какое вакантное ID "освободилось" для следующего INSERT - в мультипоточной среде такого не сделаешь, когда параллельно выполняются сотни транзакций.

Ну а если вообще рассуждать по-простому, то вот какой смысл использовать повторно один и тот же ID, если он уникален, и его задача быть уникальным? Представьте себе самый банальный вариант: зарегистрировали пациента, которому надо сделать ампутацию ноги через пару дней. Скрипт программы в регистратуре поместил запись в базу, а база при INSERT присвоила ему ID 666. А пациент возьми и умри в тот же день. Стерли его с базы, а потом зарегистрировали другого недомогающего - Васю, которому укол надо было сделать в задницу и всего делов. А база при INSERT взяла и присвоила ему вакантный ID 666. А что потом? А у доктора смена и на столе задание, которое распечатали при регистрации - ампутация ноги пациенту ID 666. Вот и попал Вася.
Ответ написан
@akdes
присоединяюсь к другим, это номральное и правильное поведение ДБ.

Если хотите пострелять себе в ногу:
после DELETE from xyz where...;
задача реагировать на удаление записей, либо програмно, либо тригерром, а далее запускать сброс счётчика на максимальный +1:
ALTER TABLE xyz AUTO_INCREMENT =
(
   SELECT sum(id +1) from xyz ORDER BY id DESC LIMIT 1
)

только это не решает проблемы, когда есть 1,2,3,4 и 2,3 удаляются.. если Вы и их хотите перезаписывать, тогда не вижу смысла в поле ID вообще
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы