Проблема стриггерами

[patch]

Доброго времени суток господа, делаю клиент-серверную БД на делфи в качестве курсовика и возникла не то что проблема а скажем так, баг который со слов преподавателя не обязателен в исправлении, но чисто для себя считаю, что надо сделать все по человечески. В общем излагаю суть проблемы

в SQL explorer создаю генераторы и триггеры для первичных ключей в таблице... у триггеров код:

*лалала то что написано всегда Before insert лалала что-то там ноль и т.д.*
begin
new.столбец=GEN_ID(название генератора, шаг);
end
и все бы ничего, но при удалении строки из таблицы ,значения первичных ключеи не меняются н-р если были строки с ключами 1 2 3 то при удалении 3ей строки и добавлении ещё одной получается 1 2 4....и мне это не нравится (да и мало кому бы понравилось)... были мысли насчет добавления ещё одного триггера с изменением на after delete, но если сделать таковой с аналогичным кодом и с шагом -1, то при удалении из середины, генератор сменится на -1 и будет равен уже занесенному последнему значению первичного ключа и тогда уверен что вылетит ошибка и придется все исправлять....

з.ы. простите что так все развернуто, в сокращении не очень получается изложить...)

[=master=]

и мне это не нравится (да и мало кому бы понравилось)...

Да с чего так? Всем нравится и даже очень, никого не знаю обиженного, вы первый.

[temaps]

new.столбец=GEN_ID(название генератора, шаг);

заменить на:

declare n int default 0;
select max(столбец) from таблица into n;
new.столбец=n+1;

[Прик]

Сообщение от =master=

Да с чего так? Всем нравится и даже очень, никого не знаю обиженного, вы первый.

Соглашусь и даже очень (+1).

[Serge_Bliznykov]

temaps, фактически Ваш совет - "мимо кассы"...

ну будет у него 1 2 3
удалит он ID=2
будет 1 3 - чему будет следующий номер?!

Сообщение от =master=

Да с чего так? Всем нравится и даже очень, никого не знаю обиженного, вы первый.

=master=, +1
вообще-то, он не первый. такие уже встречались (если надо, я тут на форуме тему найду, была такая). Но по сути я полностью согласен. Всем нравится!
А такие сложности возникают, когда кто-то пытается к первичным ключам привязаться как, например, порядковому номеру... Запомните, первичные ключи несут одну нагрузку - обеспечить уникальность записей в таблице.
Всё остальное (нумерация и т.д.) - либо заводите ДОПОЛНИТЕЛЬНОЕ поле (и перенумеровываете при необходимости), либо вообще получаете нумерацию в запросе.

[temaps]

А я понимаю ТС. Мне это тоже не нравится.

Сообщение от Serge_Bliznykov

temaps, фактически Ваш совет - "мимо кассы"...
ну будет у него 1 2 3
удалит он ID=2
будет 1 3 - чему будет следующий номер?!

Мой ответ чётко на одну из двух озвученных проблем. Вторая решается по аналогии. Можно справится и с серединой, повесив на after delete:

declare n int default 0;
select max(столбец) from таблица into n;
if (old.столбец<=n) then
update таблица set столбец=old.столбец where столбец=n;
end if;

[=master=]

temaps Я не знаю что вы понимаете, а вот то что вы не понимаете, что ваш макс+1 это мина замедленного действия, знаю.

Даже ваш after delete все-равно не рабочий.

[temaps]

Сообщение от =master=

temaps Я не знаю что вы понимаете, а вот то что вы не понимаете, что ваш макс+1 это мина замедленного действия, знаю.

Пожалуйста, пруф, если не сложно.

Сообщение от =master=

Даже ваш after delete все-равно не рабочий.

Ну надо понимать, я тут указываю идеи. Если сидеть разбирать, то у меня и в первом коде ошибка
new.столбец=n+1;
надо писать так: set new.столбец=n+1;
Я же не стал расписывать, что при таком удалении нужно, чтобы ещё форейн кеи везде каскадными упдейтами были и т.п. это уже на копание рассчитано.
Я же пишу тут не проверяя. А кому надо, тот идею обработает и сделает то, что нужно. Да, я не обратил внимания, когда писал, что триггер не может апдейтить ту таблицу из которой вызван, но это пример. Я просто показал, что при желании это сделать можно, а остальные почему-то просто отписались "а нафига"?

[Serge_Bliznykov]

temaps, не спора ради, а только истины для!
Мой Вам совет - никогда, (вы слышите - НИКОГДА) - не стоит updat'тить ключевые поля!
Это в практике прямой шаг к сложнейшим глюкам в виде повреждения целостности данных (Вы же не апдейтите те поля, которые ссылаются на данное ключевое поле), более того, это в данном случае ВООБЩЕ НЕ НУЖНО ДЕЛАТЬ! Ибо проблема у TC мнимая! Понимаете, ему НЕ НРАВИТСЯ, что ключевые поля идут не так, как ему хочется. А завтра ему не понравится, что там попадаются числа 13 или нечётные числа, или числа, которые есть в других таблицах, или ещё что-то, что ему не понравится... То же триггерочек нужно будет подправить?!!

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

Так вот вам и пытаются сказать, что нужно подумать - а нужен ли тот кошмарный ужас, которые Вы предлагаете самому TC

[=master=]

Зачем пруф? сами подумайте прутся на создание новой записи 2 запроса одновременно. Первый выхватил макс=4 и второй, первый вставил, а каков удел второму?
Вот и весь пруф.

остальные почему-то просто отписались "а нафига"?

Потому что никто не занимается этим, потому что "а нафига?".. ИД как правило (99,999%) это скрытая/системная информация , кому надо с ним возится? с каскадами и т.п. если никто не видит / не знает, а проблем можно отхватить по самое...
А номер по порядку зависит от многих условий, вставте в выборку order by (к примеру), и ваши номера полетят к чертовой матери, а следовательно их смысловая нагрузка стремительно приближается к полному нулю.
Если так уж надо некий номер по порядку, то делают так как Serge_Bliznykov в #5 указал.