После обращения к хостингу, в саппорт, ничего толкого он не посоветовал. Возможности на другой хостинг пока перейти нет.
Как можно исправить данную проблему посредством кода, чтобы auto_increment нормально работал, как итерация +1
Пробовал писал перед запросом
mysql_query("SET auto_increment = 1");
Но не срабатывает.
Спустя 9 минут, 50 секунд (7.11.2010 - 20:47) kirik написал(а):
Спустя 1 час, 20 минут, 25 секунд (7.11.2010 - 22:08) SlavaFr написал(а):
я согласен с тем, что если хостер нормальный шаг инкремента не выстовит, то его надо менять. С другой стороны, даже если инкриметн с шагом 10, то это в общем не мешает нормальному протиканию программы, до тех пор пока количество строк не достигло максималного_значения/10.
После устраненния ошибки хостером, или после переезда на другуй хост, будет не сложно для приобритения душевного покоя зделать "update tabliza set pole=pole/10".
После устраненния ошибки хостером, или после переезда на другуй хост, будет не сложно для приобритения душевного покоя зделать "update tabliza set pole=pole/10".
Спустя 9 минут, 26 секунд (7.11.2010 - 22:17) kirik написал(а):
Цитата (SlavaFr @ 7.11.2010 - 14:08) |
будет не сложно для приобритения душевного покоя зделать "update tabliza set pole=pole/10" |
Будет сложно, и это проблема.
Спустя 28 минут, 40 секунд (7.11.2010 - 22:46) SlavaFr написал(а):
Цитата (kirik @ 7.11.2010 - 19:17) |
Будет сложно, и это проблема. |
будет немного работы, так как надо также референцированные таблицы изменить, но сложности я както не вижу.
Спустя 3 минуты, 17 секунд (7.11.2010 - 22:49) Joker написал(а):
Цитата (SlavaFr @ 8.11.2010 - 00:46) |
будет немного работы, так как надо также референцированные таблицы изменить, но сложности я както не вижу. |
а вот раздели 11 на 10 получишь 2?)
Спустя 4 минуты, 9 секунд (7.11.2010 - 22:53) kirik написал(а):
Спустя 27 минут, 39 секунд (7.11.2010 - 23:21) SlavaFr написал(а):
Цитата (Joker @ 7.11.2010 - 19:49) |
а вот раздели 11 на 10 получишь 2?) |
придрался

давай тогда так (х-1)/10
при одинаковом шаге алгоритм не сложный.
Спустя 17 минут, 42 секунды (7.11.2010 - 23:39) Joker написал(а):
а теперь представь что у тебя не банальная табличка а целая база, сделай такое и все связи упадут....
Спустя 4 минуты, 39 секунд (7.11.2010 - 23:43) Pulse написал(а):
SET @@auto_increment_increment = 1
Вроде как сработало, а две собачки, что значит, типа установление системного параметра?
Спустя 7 минут, 19 секунд (7.11.2010 - 23:51) SlavaFr написал(а):
Цитата (Joker @ 7.11.2010 - 20:39) |
а теперь представь что у тебя не банальная табличка а целая база, сделай такое и все связи упадут.... |
я уже написал и то, что прийдется переделывать зависимые таблицы. в данном случае таким же алгоритмом. в случае innoDB садим FOREIGN_KEY_CHECK=0
существует и другуй вариант, с созданиме дополнительного поля @lauf:=ifnull(@lauf+1,1)
a и последовательного update.
Короче работу вижу, а сложности на вижу

А в общем если прблема с шагом инкремента в блежайшем будущем будет решена, то вообще не надо себе гогову ломать и все оставить как есть.
Спустя 6 часов, 21 минута, 26 секунд (8.11.2010 - 06:12) kirik написал(а):
Цитата (SlavaFr @ 7.11.2010 - 15:51) |
Короче работу вижу |
А я вижу извращения

Все решается одной строчкой - установкой нужного инкримента.
Цитата (Pulse @ 7.11.2010 - 15:43) |
а две собачки, что значит, типа установление системного параметра? |
Спустя 50 минут, 49 секунд (8.11.2010 - 07:03) Joker написал(а):
Цитата (SlavaFr @ 8.11.2010 - 01:21) |
давай тогда так (х-1)/10 |
(11-1)/10 = 2?





Спустя 1 минута, 44 секунды (8.11.2010 - 07:05) Joker написал(а):
Цитата (SlavaFr @ 8.11.2010 - 01:51) |
Короче работу вижу, а сложности на вижу |
не работал ты братец с базами по 5-10 гигов... сразу бы увидел сложности.....
Спустя 2 часа, 13 минут, 42 секунды (8.11.2010 - 09:18) sergeiss написал(а):
Цитата (Joker @ 8.11.2010 - 08:05) |
не работал ты братец с базами по 5-10 гигов... сразу бы увидел сложности..... |
Я даже больше скажу. Когда элементарное добавление столбца в таблице занимает более 24 часов... И не потому, что сервер медленный, а потому, что там более 36 млн. записей, в одной только этой таблице (а одна только эта таблица сколько-то-много-гигов занимает).... То тогда любые массовые изменения, действительно, являются весьма сложными.
Почему долго так? Потому, что там еще и пользователи что-то запрашивали, да ночью новые данные грузились. И эти процессы мешали друг другу, причем весьма сильно.
Естественно, апдейты будут быстрее, чем обновление структуры, но всё равно долго. Тем более, в связанных таблицах если это всё надо проделать.
Спустя 3 часа, 4 минуты, 48 секунд (8.11.2010 - 12:23) SlavaFr написал(а):
Цитата (Joker @ 8.11.2010 - 04:03) |
(11-1)/10 = 2? |
не понимаю что ты хочеш сказать. я не утверждаю, что должно 2 получится.
Цитата (Joker @ 8.11.2010 - 04:05) |
не работал ты братец с базами по 5-10 |
сейчас работаю с 4 гигабайтами, а раньше с 8 работал.
Цитата (sergeiss @ 8.11.2010 - 06:18) |
Я даже больше скажу. Когда элементарное добавление столбца в таблице занимает более 24 часов... |
да, ткой скрипт занимает много времени, но если это нужно то делаете?
в любой системе где продолжается програмирование постоянно возникает потребность делать изменения в структуре таблиц.
к стате повторюсь:
Цитата (SlavaFr @ 7.11.2010 - 20:51) |
А в общем если прблема с шагом инкремента в блежайшем будущем будет решена, то вообще не надо себе гогову ломать и все оставить как есть. |