Друзья, а не проще ли так: триггер на вставку наращивает поле Folder на 1 (Default Folder`а - 0), а триггер на удаление - уменьшает его? Тогда в нем всегда будет храниться не только факт наличия "деток" (ненулевой Folder), а еще и их количество. Пример:

CREATE TRIGGER table1_insert
ON table1
FOR INSERT
AS
IF @@ROWCOUNT = 0 'блокирование ложн. срабатывания
RETURN
UPDATE table1
SET Folder = Folder + 1
FROM inserted INNER JOIN table1
ON inserted.ID_PARENT = table1.ID
RETURN

CREATE TRIGGER table1_delete
ON table1
FOR DELETE
AS
IF @@ROWCOUNT = 0
RETURN
UPDATE table1
SET Folder = Folder - 1
FROM deleted INNER JOIN table1
ON deleted.ID_PARENT = table1.ID
RETURN

Тут в конфе где-то неделю назад один умный человек дал ссылку на потрясающую статью (впечатляющего по крайней мере меня, не шибко зубрившего основы древовидных структур). Так вот структура типа обсуждающейся в этой теме (ID, ID_PARENT) называется "направленные графы". А вот в этой статье есть описание альтернативной структуры, позволяющей хранить те же иерархические зависимости, однако объекты в этой структуре оказываются связаными математической зависимостью, зная которую влегкую строится простой SELECT для получения на основе рассматриваемого узла любого вверх или вниз по иерархии.
Я уже 3 года с "направленными графами" вобнимку, в моей структуре при добавлении объекта даже рассчитывается уровень вложенности тригером, все кульно, но: не нравится скорость "ползания" по дереву. Вот приду на работу с курсов, на которых я сейчас нахожусь - буду внедрять "альтернативу". Найдите ссылку на эту статью, почитайте, и попробуем вместе. Там есть кое-что, что мне не нравится, и я хочу применить комбинацию этих способов

2 SergSuper
Согласен. Вставлять "пачку" записей нельзя. Поэтому у себя в тригере вставил такую блокировку:
...
AS
DECLARE @rowcount INT
SET @rowcount = @@ROWCOUNT
IF @rowcount = 0 'блокирование ложн. срабатывания
RETURN
IF @rowcount > 1
BEGIN
RAISERROR('Нельзя добавлять более 1 записи',16,1)
RETURN
END
...

Самому-то мне все это не сильно нравится. Напомню, что решение организовать хранение объектов в иерархической структуре я принял в условиях лично моей низкой квалификации несколько лет назад, а когда "подрос" - приложение уже было запущено в эксплуатацию и было связано с другими приложениями по классификационным кодам (поле ID таблицы table1 имеет тип INT IDENTITY(1,1))
Приходилось выкручиваться "на ходу" и для основных сущностей предметной области создать и поддерживать реляционные (неиерархические структуры) тригерами table1. Размеры тригеров стали удручать: не меньше 500 строк для каждого события изменения данных. Кроме этого никак не удавалось найти приемлемого решения для события изменения атрибутов таких сущностей. Поэтому и нахожусь в поиске других решений.

По поводу статьи - нет, не эта, хотя эта тоже крайне интересна, еще не прочитал. Я сейчас не на работе, где и закладка на статью и любовно распечатанная и пошитая копия.

По поводу вставки пачки записей (целая ветка). Мне кажется, это можно решить только курсором, причем на содержимое поля ID должно быть наложено ограничение - по крайней мере ID "дочек" должны быть меньше ID своих "пап"