LINUX.ORG.RU

переустановить auto_increment


0

0

Всем привет.

есть таблица

CREATE TABLE IF NOT EXISTS `name` (
  `id` bigint(12) NOT NULL auto_increment,
  `name` varchar(100) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

в ней записи

INSERT INTO `name` (`id`, `name`) VALUES
(1, 'test'),
(2, 'test'),
(3, 'test');

Далее, например удаляю запись (id=2) - послу удаления auto_increment будет (1,3 ) - а мне нужно его послу удаления перебрать чтоб auto_increment опять был по порядку (1,2) - я забыл как это называется в mysql подскажите пожалуйста !

если нужно такое поведение как описано, то не надо использовать auto_increment, а надо написать свой костыль. Что будет неверно и Вам оторвут ноги/руки/голову. И будут правы.

qnikst ★★★★★ ()

Docs -> ALTER TABLE ->

To change the value of the AUTO_INCREMENT counter to be used for new rows, do this:

ALTER TABLE t2 AUTO_INCREMENT = value;

You cannot reset the counter to a value less than or equal to any that have already been used. For MyISAM, if the value is less than or equal to the maximum value currently in the AUTO_INCREMENT column, the value is reset to the current maximum plus one. For InnoDB, you can use ALTER TABLE ... AUTO_INCREMENT = value as of MySQL 5.0.3, but if the value is less than the current maximum value in the column, no error occurs and the current sequence value is not changed.

bibi ()
Ответ на: комментарий от bibi

учитывая, что при провалившихся транзакциях могут возникать «дырки», которые не удволетворяют требованиям заявленным ТС. так же непонятно, что делать при удалении значения не с конца. Вывод простой не делать так в auto_increment столбце, а создать дополнительный и триггер меняющий значения на удволетв ТС.

И вобще ключ меняться по хорошему не должен никогда

qnikst ★★★★★ ()
Ответ на: комментарий от malik555

Что-то мне подсказывает, что Ваша проблема с инкрементным полем из-за неправильного решения некой другой задачи...

Расскажите лучше, какие цели преследуете; для чего именно понадобилось так менять автоинкремент?

P.S. Таки верна мысль, что автоинкремент лишний раз лучше не дёргать. Не знаю, как в MySQL, но за PostgreSQL ручаюсь, что автоинкремент сквозной во всех транзакциях... неспроста, поверьте :)

Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

Ваша строка «из-за неправильного решения некой другой задачи» заставила меня задуматься глубже и вы оказались правы на 100% .

Спасибо ребята за помощь - с вопросом разобрался !

malik555 ()
Ответ на: комментарий от bibi

Поле id - PRIMARY KEY, БД с одной таблицей не имеет смысла, поэтому в БД могут быть другие таблицы с внешними ключами на id. Мы поменяли значения id во всех записях таблицы name, куда теперь ссылаются внешние ключи?

RR ()
Ответ на: комментарий от RR

Поле id - PRIMARY KEY, БД с одной таблицей не имеет смысла, поэтому в БД могут быть другие таблицы с внешними ключами на id. Мы поменяли значения id во всех записях таблицы name, куда теперь ссылаются внешние ключи?

Ну а сам то как думаешь? :)

hint: ...ON DELETE foo ON UPDATE bee...

bibi ()
Ответ на: комментарий от bibi

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

RR ()

mysql> SELECT * FROM test;
+----+-----+-----+
| id | idx | val |
+----+-----+-----+
| 1 | 1 | a |
| 2 | 2 | b |
| 3 | 3 | c |
| 4 | 4 | d |
| 5 | 5 | e |
| 6 | 6 | f |
+----+-----+-----+
6 rows in set (0.03 sec)



mysql>DELETE FROM test WHERE id = 4;
mysql>SET @idx=0;
mysql>UPDATE test SET idx = (SELECT @idx:=@idx+1);



mysql> SELECT * FROM test;
+----+-----+-----+
| id | idx | val |
+----+-----+-----+
| 1 | 1 | a |
| 2 | 2 | b |
| 3 | 3 | c |
| 5 | 4 | e |
| 6 | 5 | f |
+----+-----+-----+

Effect ()
Ответ на: комментарий от Effect

да. и лучше для твоих дел, держать отдельное поле, а с автоинкрементом не баловаться

Effect ()
Ответ на: комментарий от RR

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

Отвлечемся от того, что у TC таблица в MyISAM -> внешних ключей у него нет как класса. Предположим, что это InnoDB где они есть.

Утверждение: Что бы не делал TC со своей первичной таблицей* включая изменение первичных ключей, внешние ключи не пострадают. Они или синхронизируются с первичной таблицей или же операция не пройдёт - будет отлуп от MySQLа. По простому говоря, TC не сможет нарушить целостность внешних ключей.

Будет опровержение этого утверждения?

*) Естественно решение вида 'а мы выключим внешние ключи' к рассмотрению не принимается. Так можно и кувалдой по серверу херакнуть и все дела. Чтоб не мучался.

bibi ()
Ответ на: комментарий от bibi

>в MyISAM -> внешних ключей у него нет как класса.

MyISAM не реляционная БД получается? Внешний ключ это понятие теории реляционных БД и слежение за ссылочной целостностью лежит на СУБД (если она поддерживает) или на программисте.

RR ()
Ответ на: комментарий от RR

MyISAM не реляционная БД получается?

MyISAM не поддерживает внешних ключей. Ни больше ни меньше. Философские споры на тему 'реляционная БД MyISAM или нет' за рюмкой чаю - это вы уж как-нить сами.

Внешний ключ это понятие теории реляционных БД и слежение за ссылочной целостностью лежит на СУБД (если она поддерживает) или на программисте.

Если программисту сильно хочется отвечать за целостность внешних ключей руками - Бог в помощь. Каждый человек сам творец своих проблем (c) FIDO

bibi ()
Ответ на: комментарий от bibi

>>MyISAM не поддерживает внешних ключей.

Значит в MyISAM нельзя хранить данные в нормализованном виде?

RR ()

>а мне нужно его послу удаления перебрать чтоб auto_increment опять был по порядку (1,2)

Но... зачем?

YogSagot ★★ ()
Ответ на: комментарий от RR

Я знаю, хотел это услышать от тов. bibi =)

Тов. биби уже все сказал, что хотел. Сылки на док-ю по MySQL даны выше. Ссылки на википедию, думаю, сможете найти сами. Вперед, в бой. Удачи.

bibi ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.