Здравствуйте.

Есть таблица с записями, у каждого - свой id. Если у этих id стоит A_I, то возникает такая проблема: если удалить, скажем, 5 запись из 10, то 5 записи уже не будет никогда (при создании новой записи следующий id будет 11). Для порядка, имхо, неплохо бы не использовать A_I и написать скрипт, отслеживающий и обновляющий id.

Алгоритм я себе представляю примерно таким (псевдокод):

1. Добавление новой записи

В цикле

SELECT id FROM таблица

и заносим в $id_array;

$index = count($id_array);
$new_id = $id_array[$index]++;

INSERT INTO таблица (id) VALUES ($new_id);

Тут могут быть неточности с точки зрения php, не обращайте внимания - я код не продумывал, просто привожу для описания общей сути.

Новая запись имеет id на 1 больше, чем последний id в таблице. Всё хорошо. Но вот с удалением...

2. Удаление записи

В форме удаления выбираем запись, то есть id (это переменная $id);

DELETE FROM таблица WHERE id=$id;

Если удалена запись номер 5, то следом за 4 будет 6. Чтобы этого не было,

В цикле проделываем
$new_id = $id++;
UPDATE таблица SET id=$id WHERE id=$new_id;
До тех пор, пока в таблице есть ещё записи

Образовавшийся пропуск в ряде величин заполняется путём уменьшения всех id, стоящих после того, который мы удалили.

СУТЬ ВОПРОСА.

Если в таблице 10 или 20 записей - ещё ничего, но что если в блоге за несколько лет накопилась 1000 записей? Тогда, при попытке удалить 5-ю запись, запрос UPDATE будет посылаться 994 раза! Как сервер воспримет такую нагрузку?

В общем, коряво как-то выходит. Хочу спросить - есть ли какое-то более аккуратное решение?

P.S. Я слышал, что в sql-сервере предусмотрены какие-то процедуры, циклы... Может быть, не париться о php-шном "обновляторе", а сразу MySQL учить и в этом направлении курс держать?

запрос UPDATE будет посылаться 994 раза!
С фигали ?

Проблема-то где?

А что, проблемы нету?!!

Ну, то есть да - то, что чём я говорю вначале, это скорее не проблема, а нюанс. Просто мне кажется, что id необходимо отслеживать без auto increment. Не логично как-то, когда удалишь с сайта старые записи, а потом отсчёт начинается с какой-нибудь там 369-й записи... Ведь именно так будет с ai.

Мой алгоритм предполагает уменьшение всех id, стоящих после удалённого. Если записей действительно много - мне кажется, нагрузка будет большая.

Ну подумайте: берётся id, который мы удалили. Следом за ним - id большего размера, и мы его уменьшаем. Следом следом - ещё id, и его уменьшаем... Чтобы выстроить ровную цепочку: 1,2,3,4,5,6,7,8 вместо разорванной 1,2,3,4,6,7,8. Ели записей 8 или 10, то цикл будет посылать 8 или 10 запросов на переписывание следующих id. Если записей (этих самых id) ОЧЕНЬ много (сайт разросся на годы), то и запросов будет столько же, сколько стоит записей после удалённой нами. И если их 1000, то, удалив 995-ю запись, мы получим всего 5 запросов, НО если мы удалим 5-ю или 1-ю запись - посчитайте сами, сколько будет запросов.

А если стану удалять запись в тот момент, когда на сайте несколько сотен (или тысяч) посетителей??? (ну, хороший сайт, раскрученный)

Неужели для современных серверов это настолько незначительно?

Или вы хотите сказать, что вообще не стоит заниматься этим? Либо с AI, либо никак?

Нету, конечно.
AI уникален.

Видите вот этот форум? Вы можете послать кому-нибудь на эту страницу ссылку? А если я сейчас удалю, например, тему №15140? Куда человек по вашей ссылке попадёт?

Конечно, AI уникален - кто ж спорит. Вероятно, этим вы хотите сказать, что отказываться от AI не имеет смысла, не так ли?

То есть, идея самому контролировать заполнение id - изначально тухлая затея?

Да.