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

gardenman 4321[quot gardenman]или же текстового (мемо) поля с полной иерархией узла.

А ну-ка перепоlчините одну ветку - другой... :)) Любопытно взглянуть на количество кода, которое придется нарисовать при этом, а так же на производительность этого чуда :)Я делал несколько другой случай - триггера для заполнения "полной таблицы связей" в постгресе (т.е. "на каждую запись". Делал без использования касадного срабатывания триггеров (т.е. запись в таблице дерева отрабатывала свой триггер, правя ВСЕ порождаемые этим изменения таблицы связей SQL конструкциями (на основе той же самой таблицы связей)). При вставке/редактировании отдельных записей пользователями работает приемлемо. Наиболее критичны массовые вливы/апдейты данных какой-нть приладой. Кода "изрядно" (по полстранички на адд -2 инсерта, и 3/4 - на апп - несколько дилетов и инсертов). Но "полчаса потерять" - а дальше можно код просто юзать для других деревьев..


Для текстовой иерархии в поле очевидно порождение каскадного срабатывания триггеров (если поле в той же таблице) "на запись". От этого мне хотелось уйти. Можно наверное иерархию держать в таблице связанной 1-1. Но мне не улыбалось писать Лайки (они у постгреса как-то криво работают со стандартными индексами, а я был "не в теме").