Архив форумов ЦИТФорума

[Santo]

Народ вернемся к старому, есть гостевая книга, в ней сообщения идут по порядку 1,2,3,…
Эти сообщения выводятся на экран пользователя в таком же порядке, (использую MYSQL 4 поля: дата, имя, комментарий, и номер сообщения для этого поля устанавливаю auto_increment, primary key). Не нравиться комментарий номер 3 его надо удалить, загружаю страницу в которой только поле для ввода номера ненужного сообщения, поиск удаляемой записи осуществился по номеру сообщения. Нет поля номер 3 т.е. теперь сообщений на одно меньше и порядок следующий 1, 2, 4,…. Такой вопрос каким образом восстановить нормальный порядок сообщений т. е. 1,2,3,…?
P.S. Несколько дней назад я слышал от участников этого форума, что с update не надо связываться.

[and3008]

Вообще все нормальные люди делают так:
Ключи делают уникальными (автоинкрементными например), а всякую оформиловку (номер по порядку, сумма прописью, вычисления) делают динамически.

Тогда не будет никаких проблемм с содержимым базы и отображением данных.

[Miky]

Как учасники форума мотивировали свою рекомендацию? По-моему update прекрасно работает.

[yoshi]

Вполне прилично работает.
Вот кстати я встречал достаточно реализаций, где автоинкремент работает некорректно

[Santo]

Народ я с вами тоже согласен, а синтаксис какой у update, напишите пожалуйста, не могу найти не одной нормальной документации по работе с таблицами!!!

[yoshi]

UPDATE table
SET col=expression
[WHERE condition]

Ферштейн?

[and3008]

Я чё-то не понял.
Update для всех записей что ли делать?
Мдя...
Либо гостевая книга действительно слишком скромная, либо я слишком много работаю с большими базами данных...

[Miky]

Ну вообще-то я рассуждал так, когда делал гостевую книгу: Модерить я ее буду примерно раз в неделю, за неделю много ли напишут, а update-тать нужно только записи, которые появились после "неугодной" это не так много. В общем случае конечно это возможно не слишком элегантное решение, но для сайта с небольшой посещаемостью вполне приемлемое

[and3008]

Ну тогда дерзай. Решение не слишком элегантное...

[Miky]

Только Гостевую нужно отображать и на каждой станице одинаковое количество комментариев, скажем 10. А внизу ссылки на дугие страници ну типа [1] [2] [3] ... и тд (и на каждой строго по 10 страниц!). Обычная Гостевая.
Мое решение позволяет получить содержимое каждой страници двумя запросами, один из которых довольно быстрый select count(*) from guestbook, а второй вытащит мне в результирующем наборе мои 10 записей не БОЛЬШЕ и не меньше.
Если у тебя есть решение обладающее этими достоинствами при выборке и не требующее "массовой" модификации записей при модерировании, я очень бы хотел посмотреть на него.

[Борис]

Как я понял из переписки, нумерация требуется для того, чтобы можно было задать диапазон номеров с одинаковым количеством для вывода одной порции информации. То есть ты используешь count(*), чтобы посчитать количество порций, а затем по номерам выделяешь нужную порцию для вывода.
При таком подходе поле номера выполняет роль индекса и, естественно, просто обязано "update'иться" при изменении любого порядка. Вопрос в том, как обеспечить безошибочность при изменении (ключевых) данных. Сложность в том, что не зная алгоритма работа update, невозможно гарантировать, что эта операция не попытается создать недопустимые (дублирующиеся в твоем случае) ключи. Об этом и говорится в советах "не связываться с update". А обеспечить безошибочность очень просто: обновлять не целиком таблицу одной операцией update, а по одной записи, выбрав такое направление обхода записей, которое гарантирует создание недублирующихся ключей. Примерно таким образом (считаем, что максимальный_номер нам известен после select count(*)...) (запись в C-подобном псевдокоде):

Удаление записи #3 (с 4-ого по последний номера уменьшаются)
--------------------------------------------------------.. from таблица where номер=3;
тек_номер = 4;
while (тек_номер = 3) {
update таблица set номер=номер+1 where номер=тек_номер;
тек_номер--;
}
insert into таблица (номер) values (3);

По скорости работы этот варианта сопоставим со скоростью одной команды update по всем записям.

Все это, конечно, IMHO.

PS. Этот подход требует лишних замен номеров, так как для вывода нужной страницы по сути требуются не номера *каждой* записи, а номера записей, которые будут *первыми* на соответствующей странице. Поэтому для ускорения работы выгодно создать отдельную таблицу "первых" номеров страниц (такой искусственный индекс) и описанное делать применительно к этой таблице.