Коллеги, подскажите, пожалуйста, следующее. В таблице есть автоинкрементное поле id. В результате ошибки в скрипте в таблицу набилось множество некорректных значений, которые были после удалены. Но после них осталось много неиспользованных значений в столбце id. Автоинкремент из этого столбца я убрал. Скажите, как можно повторно использовать id удаленных записей? Как найти первую цифру в первом разрыве id, чтобы использовать ее в качестве id для новой записи? Например, в столбце идет последовательность id: 1, 2, 8, 9, 10. Как мне получить из него цифру 3?
этого не стоит делать просто потому, что автоинкрементные поля не предназначены для того, чтобы заполнять в себе дырки - нужно понимать суть автоинкрементного поля! а счётчики, порядковый номер записи, общее кол-во записей, постраничный вывод и т.д... делаются по-друому.
Читайте внимательнее - автоинкремент с этого столбца я убрал. А делать стоит - слишком много дыр получилось и они слишком большие.
Я делал при помощи вот этого http://ru.wikipedia.org/wiki/Двоичный_поиск Запросов 10-15 на каждую вставку придется сделать.
Nikolai_ Можешь поискать, но 99% его нет А какая кому разница чему ID-шки равны? Они не для человека, они для машины.
Подумал тут... А если так сделать? По моему очень просто получается, без всяких 10-15 запросов. Код (Text): $query = mysql_query("SELECT id_album FROM gallery_album;"); $c=1; while ($q = mysql_fetch_array($query)){ if($q['id_album'] > $c){ $id_new = $c; break; } $c++; }
Есть стопятсот решений, только По-этому верните автоинкремент и забивайте голову чем-то еще. Ваше ПО должно быть рассчитано на работу с рваными ID.
А выше тут человек писал, что есть только одно решение с 10-15 запросами и больше в 99% я не найду. Мне есть разница. У меня в общем максимум должна быть 3-значная цифра. А мне набилось уже до пятого знака. Какого рожна мне нужны этих лишних 2 порядка? И вообще я не понимаю чем плохо повторное использование id? То решение, которое я привел, вполне подойдет? Как думаете?
Плохо тем, что человек зацикливается на этом и начинает писать софт исходя из непрерывности, а поиск дырок - очень накладная операция. В итоге получается полный 3.14 и при этом никому не нужный. Если нужно один раз привести большую базу "в порядок" - это еще можно понять, если же собираетесь каждый раз после удаления записи такое делать - это бред. Для мускуля можно так mysql> SET @id:=0; mysql> UPDATE tablename SET id=(@id:=@id+1);
Удаление нескольких десятков тысяч некорректных записей - это была разовая акция. После того, как ошибка в скрипте была исправлена, больше ничего удаляться оттуда не будет. Мне так и не объяснили, чем плохо повторное использование id уже удаленных записей? Вот плохо и все, а почему - никто не знает. Тем более, что решение для этого я привел крайне простое, а не с 10-15 запросами, как предлагал один коллега. Ничего накладного я там не вижу - там в таблице всего будет не более 1000 записей. Перебрать их, найти дырку и создать новый id не создаст никаких особых нагрузок.
плохо будет, если у тебя есть ссылки на удалённые записи в других таблицах. это всё равно что страницы на сайте - вот была у тебя страница по адресу http://www.site.com/index.php?page=134 удалил из базы страницу 134, а затем вместо неё с таким же номером вставил другую. итог: гугл выдаёт одно, яндекс выдаёт другое, а по факту там хранится совсем не то, что нужно. так же и с автоинкрементным полем - оно должно быть уникальным в пределах жизни всего проекта. можно конечно и повторное использование, если в других таблицах не имелись ссылки на удалённые записи
Ссылок с других таблиц на эту не было. Поэтому тут все карты в руки, чтобы использовать эти id повторно.
ID важен для ссылочной целостности, если у тебя таблица - сферический конь в вакууме, то нафига вообще id? Для красоты? Твой способ на 1000 записей уже будет давать заметную задержку, когда id подберется к 900. Если нужно разово удалить - всё проще делается. CREATE table2 LIKE table1; INSERT INTO table2 (field1, field2, field3) SELECT field1, field2, field3 FROM table1; DROP table1; RENAME table2 TO table1;
Обращение к этой таблице происходит 3-4 раза в месяц - при загрузке нового альбома с фото создается запись о нем. Поэтому, если там даже надо было бы перебирать 10000 записей, то это была не проблема.