Дерево в БД - проблема при удалении узла

← →
trubin © (2008-05-01 21:35) [0]

Здравствуйте, появилась вот проблемка:

имеется таблица в БД, в которой храниться древовидная структура, конкретнее эта таблица используется для хранения элементов файловой

системы. Кусок DDL:

CREATE TABLE FILES( ID NUMERIC(18,0), /*первичный ключ*/ PARENT_ID NUMERIC(18,0), /*ключ родителя*/ CHILD_COUNT INTEGER, /*количество потомков*/ ... );

имеется триггер after delete:

CREATE TRIGGER TR_AD_FILES_0 FOR FILES ACTIVE AFTER DELETE POSITION 0 AS BEGIN /*УМЕНЬШАЕМ СЧЕТЧИК ПОТОМКОВ У РОДИТЕЛЯ*/ IF (OLD.PARENT_ID > 0) THEN UPDATE FILES F SET F.CHILD_COUNT = F.CHILD_COUNT - 1 WHERE F.ID = OLD.PARENT_ID; /*УДАЛЯЕМ ПОТОМКОВ ДАННОГО ЭЛЕМЕНТА*/ DELETE FROM FILES F WHERE F.PARENT_ID = OLD.ID; END ;

ПРОБЛЕМА: при удалении узла дерева имеющего множество потомков на многих уровнях вложенности выскакивает ошибка:
"Too many concurrent executions of the same request"

Это, я так понимаю из-за рекурсивного вызова триггером самого себя. Как бы этого избежать? Не хочется городить какие-то сложные

алгоритмы для удаления. Посоветуйте.

← →
PEAKTOP © (2008-05-01 22:33) [1]

> "Too many concurrent executions of the same request"

Это где-то у тебя на триггере или ХП сервер рекурсивно в бесконечный цикл уходит. По умолчанию - не более 1000 уровней рекурсии положено.

Или данные в таблице корявые, или еще где-то триггер есть, который ты не привел.

← →
trubin © (2008-05-01 23:48) [2]

> Или данные в таблице корявые, или еще где-то триггер есть,
> который ты не привел.

Триггер на delete один во всей базе

← →
DrPass © (2008-05-02 02:12) [3]

Поставь его на before delete

← →
MsGuns © (2008-05-02 02:43) [4]

Групповое удаление на само по себе опасная штука, а если оно еще зашито в триггер, то неприятности обеспечены

← →
trubin © (2008-05-02 10:55) [5]

> Поставь его на before delete

Сразу пробовал - та же картина

> MsGuns © (02.05.08 02:43) [4]
> Групповое удаление на само по себе опасная штука, а если
> оно еще зашито в триггер, то неприятности обеспечены

Это я понимаю, вот только сколько не гуглил, книжки не листал особо не помогает...

Буду думать :)

← →
trubin © (2008-05-03 18:55) [6]

> PEAKTOP © (01.05.08 22:33) [1]

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

← →
Prohodil Mimo © (2008-05-03 20:39) [7]

а ON DELETE CASCADE не помогает или это хуже триггера?

← →
PEAKTOP © (2008-05-03 23:14) [8]

> а ON DELETE CASCADE не помогает или это хуже триггера?
На версионнике ? Еще раз повторяю: не на блокировочнике, а на версионнике FOREIGN KEY на саму себя ?

> проблема была в данных
Деревья просто снятся но ночам :) в кошмарах ...

PEAKTOP © (03.05.08 23:14) [8]
а почему нет? всё же происходит в одной транзакции.
С деревьями в FB не работал, а потому не пробовал. Можно чуть подробнее или ссылку на конкретнуу статью, почему нельзя ON DELETE CASCADE на версионнике FOREIGN KEY на саму себя?

← →
sql (2008-05-04 14:34) [10]

Скорее всего у тебя в дереве есть циклическая ссылка. То есть кто-то из потомков является предком одного из своих родителей. Или же предком самого себя. Скорее всего из-за этого и возникает у тебя бесконечная рекурсия.

Дерево в БД - проблема при удалении узла Найти похожие ветки