Forum Webscript.Ru
Общие => Базы данных => Тема начата: CGVictor от 24 Августа 2004, 10:37:30
-
Задача: пронумеровать все записи в таблице. Скажем, в столбце `id`.
[off]Т.к. уже нашлись люди, которые не поняли, объясняю:
Было:
`id`- `somevalue`
23 - 234
42 - 456
53 - 928
и т.д.
Стало
1 - 234
2 - 546
3 - 928
[/off]
Как это делать одним запросом? Как указать в запросе, что в столбец `id` должен попасть порядковый номер записи?
-
Порядковый номер относительно чего?
[OFF]ты теорию множеств учил?[/OFF]
-
Croaker
Относительно того, как UPDATE перебирает строки. Номер (порядковый).
[off]Даже если и учил - не помню. А что?[/off]
-
Хе хе.
Триллер "ЦГвиктор на граблях". 118-я серия.
Занимайте место в партере.
-
Т.к. уже нашлись люди, которые не поняли
Так это чучело называет людей, которые пытались, видимо, объяснить ему всю бессмысленность этой затеи.
Оно думает, что если сменить форкм, то глупость вдруг перестанет ей быть
-
CGVictor:
Номер (порядковый).
Отлично. Но порядковый номер ты сам задаешь. Поле id твое в принципе и есть уникальный номер записи, который можно использовать и как порядковый. Только с чего ты взял, что UPDATE (и вообще - при чем тут UPDATE) работает по ТВОЕМУ полю?
-
CGVictor,
попробуй ALTER TABLE test DROP COLUMN id, ADD COLUMN id INT AUTO_INCREMENT PRIMARY KEY, ORDER BY id; (если я правильно тебя понял)
-
Forza
И все связи, если они есть, рвутся нахрен.
-
Croaker,
А как же им не рваться, если стоит задача изменить значения всех id в таблице? [OFF]или я не догоняю?[/OFF]
-
Forza
Стоит задача объяснить человеку, что делать этого не надо.
-
Croaker
Если хочет - пусть попробует. Может, в этом есть смысл.
-
если в этом есть смысл, то человек, у которого есть хоть капля мозгов в голове, поймет, что тогда ему поле Id вообще нахрен не нужно.
-
CGVictor
зачем тебе это нужно ?
Чем не устраивают данные
23 - 234
42 - 456
53 - 928
?
Почти наверняка, это задача из разряда "Ты не должен этого хотеть"
-
Итак.
1.Поле `id` могло называться и по другому.
RomikChef:
которого есть хоть капля мозгов в голове, поймет, что тогда ему поле Id вообще нахрен не нужно
Возможно. Зависит от их наличия.
2.Forza:
AUTO_INCREMENT PRIMARY KEY
Э-эх, идея хорошая, но двух автоинкрементов в таблице быть не может.
3.Croaker:
если они есть
Считаем, для прозрачности вопроса, что их нет. Допустим, по ним только сортировка происходит
4.RomikChef:
Оно думает, что если сменить форкм
Форум здесь ни при чем. Предпочитаю общаться с 1)умными людьми 2)в реале.
Попробую немножко скорректировать вопрос.
Допустим, есть поле `sort` (это чтобы любители `id` молчали). Есть выборка по какому-то условию (не важно). Выборка дает нам какие-то записи. И вот теперь нужно эти записи в поле `sort` пронумеровать с единицы и далее.
Question clear?
-
CGVictor:
И вот теперь нужно эти записи в поле `sort` пронумеровать с единицы и далее.
Зачем?
-
SET @sort := 0;
UPDATE tab SET sort = @sort := @sort + 1 ORDER BY date;
-
Чего накинулись на человека? :) Может из спортивного интереса...
-
Croaker:
Зачем?
У меня задача - написать интеграцию с very, very hemmoroidal database... Не я это придумывал изначально.
Макс
Спасибо! Попробую!
-
CGVictor
Тем не менее. Опиши конкретную задачу, для которой тебе понадобилось так оптимизировать базу.
-
Croaker
Опиши конкретную задачу, для которой тебе понадобилось так оптимизировать базу
Позволю себе описать:
Есть таблица где хранится дерево каталогов, в нем сортировка своя, и трогать её не будем, а есть вторая таблица записи которой относатся к разным узлам дерева. Причем к узлу может относится разное количество записей. Как производить их сортировку?
Создаем дополнительно поле sort в котором мы указываем свой(!) порядок для каждого узла:
id | title | category | sort
1 | title1 | 1 | 1
2 | title2 | 1 | 2
3 | title3 | 1 | 3
4 | title4 | 2 | 1
5 | title5 | 2 | 2
6 | title6 | 2 | 3
7 | title7 | 2 | 4
8 | title8 | 3 | 1
9 | title9 | 3 | 2
10 | title10 | 4 | 1
...
Добавляя дополнительные записи в узел, мы просто бепем максимальное значение поля sort для данного узла и устанавливаем на 1 большую
Перемещение порядка скажем на 1 пункт вверх (вниз) происходит учень просто: в одной записе sort уменьшеем на 1 в другой увеличиваем...
Все работает прекрасно до того момента пока мы не начнем удалять записи, тогда у нас между некоторыми записями разница sort будет больше чем еденица, и соответсвенно наш замечательный запрос перемещения записи работать не будет. мало того, испортит весь порядок...
Когда запись удаляется одна, проблем особых нет: просто уменьшаем поле sort последующих записей группы на 1. А если записией удаляется сразу несколько, причем не подряд, а выборочно из определенного узла? Тогда просто проводим подобие индексации поля sort на восстановление порядка.
Вообщем-то вся трабла возникает из-за запроса перемещения +-1 поля sort. Да еще если мы перемещаем запись на несколько пунктов вверх (вниз)...
К id судя по всему, я надеюсь, в данном вопросе это поле не имеет никакого значения...
-
Phoinix
Спасибо!
У меня тот же случай, но все это уже реализовано very-very кривыми руками в корпоративной базе. И надо с этим работать.
А в чистом виде задача выглядит именно так, как ты описал.
-
попробуй новый столбец создать id2, который будет как раз пронумерован.
И связи никакие не рвутся.
В вообще когда встречаешься с такими задачами не стоит проверять sql на прочность. попробуй сделать по-другому....
всегда есть backdoor.