|
|
|
| есть таблица:
id field
1 45
2 33
3 84
4 23
5 20
6 93
7 15
8 74
9 21
можно ли одним стандартным sql-запросом, используя только одно значение id и одно значение field, обновить поле field так, чтобы получился результат в виде:
id field
1 45
2 33
3 102
4 103
5 104
6 105
7 106
8 107
9 108 | |
|
|
|
|
|
|
|
для: psychomc
(02.04.2010 в 12:32)
| | А почему строка 1 45 осталась неизменной
а 9 21 превратилась каким-то чудом в 9 108
21--108
74--107
45--45
В этом есть какая то закономерность? | |
|
|
|
|
|
|
|
для: oliss
(02.04.2010 в 12:59)
| | старые записи никак не влияют на новые. нужно обновить список с определенного id или сначала, не важно. чтобы значения шли по порядку, начиная с заданного (в данном случае 102)
то есть вопрос в том, как одним запросом обновить поля в таблице таким образом, чтобы их значения инкрементировались, вне зависимости от существующих значений, от какого-то начального значения
примерно как и
update table set field = field+1
|
только здесь учитывается старое значение, а мне это не нужно
в цикле это можно сделать, но тогда будет много запросов, а хотелось бы одним
извиняюсь что сразу не объяснил. надеюсь теперь понятно | |
|
|
|
|
|
|
|
для: psychomc
(02.04.2010 в 14:10)
| | у строк в таблице нет собственного порядка, кроме яавно заданного определенным полем.
Поэтому никаких field = field+1 нет и быть не может.
Может быть лишь update table set field = id -3 + 102 WHERE id BETWEEN 3 AND 9
если считать, что id - это поле, задающее порядок. Что обычно действительности не соответствует. | |
|
|
|
|
|
|
|
для: Trianon
(02.04.2010 в 15:07)
| | спасибо, всё ясно
суть проблемы подробнее
есть таблица
id pos
5 1
8 2
9 3
34 4
55 5
77 6
12 7
91 8
53 9
нужно удалить запись с id 9, 55, 91
id pos
5 1
8 2
34 4
77 6
12 7
53 9
каким образом оптимальнее всего сохранить порядок позиционирования чтобы было так
id pos
5 1
8 2
34 3
77 4
12 5
53 6
удаляя записи запросом
delete from `table` where id in(9, 55, 91)
|
без использования цикла? | |
|
|
|
|
|
|
|
для: psychomc
(02.04.2010 в 15:24)
| | проблема в том, что потребуется пересчитать заново столбец сортировки pos | |
|
|
|
|
|
|
|
для: oliss
(02.04.2010 в 18:09)
| | я просто вижу решение как-то так:
1) найти минимальную позицию из всех удаленных записей min(pos)
2) извлечь все id записей, у которых pos>min(pos), отсортировав их ORDER BY pos ASC
3) обновить извлеченные записи в цикле (min(pos)++), на каждую запись по запросу
оно то будет работать. но мне не нравится то, что количество запросов зависит от количества записей, и если записей скажем 3000, то и запросов на обновление может быть столько же (в зависимости от того, как высоко находится минимальная удаляемая запись). в общем-то пробовал обновлять и 50000 записей таким же способом, отрабатывает меньше чем за секунду.
но может есть более грамотное решение проблемы? спасибо за участие в теме | |
|
|
|
|
|
|
|
для: psychomc
(02.04.2010 в 15:24)
| | а порядок позиционирования при удалении не поменяется.
Дырки возникнут - да. Порядок же следования pos не изменится. | |
|
|
|
|
|
|
|
для: Trianon
(02.04.2010 в 18:23)
| | не хочется чтобы дырки возникли... хочется чтобы они все шли подряд | |
|
|
|
|
|
|
|
для: psychomc
(03.04.2010 в 13:36)
| | аргументы?
"Красиво выглядит" - не аргумент.
Поверьте, я на этом нажигался.
У Вас, конечно, случай не такой вопиющий.
Но лиха беда начало. Но следующий шаг - ради фальшивой красоты захочется первичные ключи без дырок держать - а тут уже просто хоть караул кричи. | |
|
|
|
|
|
|
|
для: Trianon
(03.04.2010 в 14:30)
| | я вас понимаю, это проще и в принципе никак не мешает функционалу. да, действительно хочу это делать только ради красоты. первичные ключи однозначно не понадобится, т.к они явно не видны.
тогда ответьте пожалуйста на один вопрос
вот на ваш взгляд: 1) мой подход ненужный и нерациональный, чтобы заморачиваться и искать какие-то оптимальные решения или 2) имеет право на жизнь
? | |
|
|
|
|
|
|
|
для: psychomc
(03.04.2010 в 15:28)
| | я полагаю, что цеплять на эту непрерывность значений какой-либо функционал - порочно в принципе.
А если оная нужна лишь ради красоты, то нетрудно запустить раз в сутки скрипт, который пройдется по таблице и подчистит дырки. Вылизывать его (этот скрипт) до полного оптимума особого смысла нет, так как цель его вторична, а запускается он редко, и вследствие этого много каши все равно не съест.
PS. Хотя с помощью условной операции CASE наверное и возможно составить выражение кусочно-линейного преобразования, которое выкинет дырки за один запрос. Исключительно фарсу ради.
PPS. вот такой он мой взгляд, точнее голос - чисто совещательный. | |
|
|
|
|
|
|
|
для: Trianon
(03.04.2010 в 15:37)
| | спасибо , в общем-то всё предельно понятно :)
и отдельное спасибо за интересные мысли | |
|
|
|
|
|
|
|
для: psychomc
(03.04.2010 в 15:28)
| | я вас понимаю, это проще и в принципе никак не мешает функционалу. да, действительно хочу это делать только ради красоты. первичные ключи однозначно не понадобится, т.к они явно не видны.
иными словами вы хотите эти порядковые номера достать из базы и вывести рядом с чем-то?
и нафига спрашивается козе баян? когда подобного прода приблуды нумеруются "налету" при выводе в браузер. | |
|
|
|
|
|
|
|
для: Valick
(03.04.2010 в 17:21)
| | нет. здесь нумерация на лету при выводе не идет, т.к при выборе этой записи, например для редактирования, значение этого поля будет не соответствовать значению, которое было при выводе в списке | |
|
|
|
|
|
|
|
для: psychomc
(03.04.2010 в 18:25)
| | для редактирования в ссылку суют id строки | |
|
|
|
|
|
|
|
для: Valick
(03.04.2010 в 20:15)
| | я знаю. значение позиции будет не соответствовать | |
|
|
|