Есть таблица (Table1) с одним полем (Num) , уникальным
Значения - 1, 2, 3, ..., 10
Как, начиная с, скажем, "3", сдвинуть все на 1 вверх, чтоб вышло:
1, 2, 4, 5, 6, 7, 8, 9, 10, 11

update Table1 set Num=Num+1
where Num>=3 - фиг там: "Ошибка первичного ключа"

Есть несколько способов:

1) FOR

FOR select Num from Table1
where Num >= 3
order by 1 Desc
INTO :Rec
DO
update Table1 set Num=Num+1
where (Num=:Rec);

2) убить уникальный индекс , выполнить апдейт, а потом создать индекс заново

3) update за область существующих номеров и потом назад со сдвигом на 1:

select max (Num) from Table1 into Rec;
update Table1 set Num=Num+Rec where Num>=3;
update Table1 set Num=Num-Rec+1 where Num>=Rec;

4) использование доп. поля в уникальном ключе

Я сейчас морочусь через "FOR SELECT... DO..." (просто это первое, что пришло в голову, и для моего кол-ва записей не тормозит)
А можно как-то попроще? Как-нибудь извернуться update`ом все-таки?

И что будет производительней?

Johnmen>Scream

А в чём сокральный смысл данного действа ?

Смысл в том, чтобы сдвинуть данные, не вызвав " violation of PRIMARY or UNIQUE KEY... ". А в освобожденное место чего-нибудь вставить.

fedd/topic/39836&hl=
Спасибо, довольно познавательно.
Похоже, вопрос оказался не таким глупым, как мне казалось сначала...

Там в обсуждении промелькнула такая идея:

Ex_SoftДаже есть модификаторы
Грабер писал:
...DEFERRABLE - (отстроченные, т.е. выполняемые с отстрочкой) или NOT DEFERRABLE (срочные, т.е. выполняемые сразу. Если определение отсутствует, то по умолчанию используется значение NOT DEFERRABLE...

Она продолжение имела? Можно где-то скрипт с этим самым DEFERRABLE увидеть? И какие SQL-сервера поддерживают его?

М-даа, оффтопика развелось... После fedd ничего полезного сказано не было :(

Мимопроходящий, спасибо за курсор! На 150 000 записях стало ощутимо быстрее.

Johnmen, не могу понять, чего же ты все-таки не можешь понять? :) Может, ты знаешь что-то, чего не знаю я? Касательно этого вопроса, я имею ввиду?

Мимопроходящий, я сдвигаю не по PRIMARY KEY, а по уникальному индексу.

fedd, я пишу менеджер для интеллектуальных весов DIGI разных моделей. Там в них надо закачать кучу разных файлов настройки - товары, этикетки, сопутствующие сообщения... и в том числе раскладку клавиатуры. И на одну клавишу можно назначить несколько разнвых товаров - типа продавец нажимает на эту клавишу, а на дисплее высвечиваются товары в определенной последовательности. Вот эту последовательность и надо запрограммировать с помощью таблицы такого типа, как я привел.

Короче - сдвигать-таки надо...

VagonПравильный ответ - убитие индекса: в среднем, Вы меняете половину записей в таблице, => и 50% индекса.

:( В том-то все и дело, что в моем случае я меняю не более 1% записей в таблице...

VagonВ описании ALTER INDEX ACTIVE/INACTIVE разработчики советуют убивать индекс при вставке/удалении 15% записей либо изменении 10%.
Хммм..... Спасибо за информацию. Есть смысл переделать другие триггера в моей базе ;)

VagonА вообще, по-моему, Вы совершенно зря сделали индекс уникальным - на ссылочную целостность БД этот ограничитель в Вашем индексе совершенно не влияет (как мне видно отсюда :).

Так-то оно так... Но хотелось бы, чтобы база сама следила за уникальностью номеров в данном случае. И до сих пор хочется.
Хотя я все равно после того, как столкнулся с такой проблемой, два раза менял идеологию данного куска базы...

--
LET`S ROCK!

Ладно, фиг с ним, с этим сдвигом - есть уже 4 способа, какой-то лучше, какой-то хуже, но все работают.

А вот как в такой таблице поменять местами две записи? То есть - было "1, 2, 3, 4, 5", а стало - "5, 2, 3, 4, 1"?

--
LET`S ROCK!

2 a:

))))) Веселый ответ
А если не одно? Если там составной индекс и куча полей, по которым к таблице привязаны другие таблицы?

Кстати, даже если поле одно - напишите скрипт, который в триггере before update менял бы местами две записи?

--
LET`S ROCK!