Нумерация topic_id

Вопросы
На чистой системе публикуем топики (допустим 4). Им присваиваются id по порядку публикации: 1, 2, 3, 4.
Теперь удалим топики 3 и 4.
Публикуем еще один топик. Теперь в таблице такая нумерация: 1, 2, 5.
Вопрос: Как сделать, чтобы топикам присваивался id, следующий за последним?
Т.е. чтобы было 1, 2, 3.

7 комментариев

avatar
никак т.е. лучше этого не делать т.к. это автоинкремент примари ключа таблицы топиков.

если конечно это нужно сделать один раз — можете через пхпмайадмин в свойствах таблицы изменить значение. если хотите программно — лучше отказаться от этой идеи т.к. придется после каждого удаления топика исправлять значение инкремента на максимальный текущий + 1
avatar
Это определяется не LS, а принципом работы базы данных с автоинкрементирующимися идентификаторами таблиц.
А вообще, если возникла такая странная задача, то это реализуется с помощью следующей SQL-команды:
ALTER TABLE `prefix_topic` AUTO_INCREMENT=3

Здесь «3» — номер, с которого будет продолжаться нумерация.
avatar
А почему странная?
А если будет некий скрипт, определяющий первое свободное поле и вставит данные с соответствующим AUTO_INCREMENT?
avatar
А почему странная?
Потому что бессмысленная. Экономить идентификаторы — бессмысленно, Вы даже близко не приблизитесь к максимальному значению.
Кроме того, если существовал топик с номером 3, его удалили, то логично, что все ссылки на данный топик должны выдавать 404 ошибку, а не вести на топик совсем с другим содержимым.
А если будет некий скрипт, определяющий первое свободное поле и вставит данные с соответствующим AUTO_INCREMENT?
Высказывание «с соответствующим AUTO_INCREMENT» не корректно. AUTO_INCREMENT имеет служебное назначение, относящееся к структуре таблиц в БД.
Если подразумевалось «с соответствующим индексом», то воможны 2 ситуации:
1) Скрипит определил максимальный индекс (например, 3), пользователь изменил AUTO_INCREMENT (тоже 3), скрипт записал данные. В этом случае AUTO_INCREMENT автоматически будет увеличен до 4, все будет работать без проблем.
2) Пользователь определил максимальный индекс (например, 2), но в момент пока он собрался изменить значение, внешний скрипт добавил данные (с индексом 3), после чего пользователь все-таки изменит AUTO_INCREMENT (на 3). В этом случае либо следующая операция записи (без заданного идентификатора) потенциально может выдать ошибку, затереть предыдущее значение, а может и корректно отработать (в зависимости от типа БД и настроек).
avatar
Процесс небыстрый, можно, например, выполнять раз в неделю.
Обязательно нужно закрывать доступ к сайту на это время.
Последовательность шагов следующая:
1) Найти все таблицы, которые используют внешние ключи, ссылающиеся на topic.topic_id.
2) Создать новую колонку (напр. topic_id_new) в таблице topic c auto_increment = 1;
3) Удалить внешние ключи c topic_id (нужно запомнить с каких таблиц), которые ссылаются на таблицу topic. Порядка 5-7 таблиц.
4) Если в какой-то из таблиц topic_id является primary, то нужно создать новую колонку (напр. id_new) с автоинкрементом. topic_id поменять тип индекса на index, id_new на primary. Удалить topic_id. Переименовать id_new обратно на topic_id.
5) В остальных таблицах, где topic_id не primary, нужно поменять значения topic_id на новые из topic_id_new.
6) Удалить topic_id из topic, поменять тип индекса на primary, переименовать topic_id_new в topic_id.
7) Создать заново все внешние ключи.
Опционально, после 5 шага можно попробовать изменить внутренние ссылки в контенте, чтобы не было казусов с неправильными ссылками.
avatar
2) Создать новую колонку (напр. topic_id_new) в таблице topic c auto_increment = 1;
в одной таблице не могут быть два поля с автоинкрементом.
avatar
Что это меняет? Во вменяемых gui это делается автоматом.
ALTER TABLE `prefix_topic`
ADD `topic_id_new` int(11) unsigned NOT NULL AUTO_INCREMENT UNIQUE FIRST,
CHANGE `topic_id` `topic_id` int(11) unsigned NOT NULL AFTER `topic_id_new`,
AUTO_INCREMENT = 1;
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.