Манго-МангоЧто-то не так с вопросом?А какой ответ Вам ждете ? Вы решили расширить метод "вложенных множеств" под конкретную ситуацию, добавив несколько "фенечек". Все работает ? Ну и слава Богу. Проблема-то в чем ?

P.S. IMHO, метод Nested Sets одним из самых неудачных способов реализации иерархических связей. Но это уже совсем другая тема.

Манго-Манго ChAP.S. IMHO, метод Nested Sets одним из самых неудачных способов реализации иерархических связей. Но это уже совсем другая тема.

хм, ну почему же, даже очень интересно... давайте её разовьём!А смысл ? Поиском Вы и без меня пользоватся умеете, сравнивать, надеюсь, тоже. Да и статей со сравнениями навалом.
Собственно из первого поста
Манго-Мангоиз-за достаточно накладных расходов при вставке, удалении, перемещении и прочее элементов в дерево. Это и есть основной недостаток Nested Sets, только в нем добавление или удаление элемента может вызвать обновление LR-значений практически всех остальных элементов дерева, хотя остроту проблемы и можно несколько сгладить непоследовательной нумерацией пути обхода. Собственно, как эта, так и другие проблемы этого метода описаны во множестве статей, нет смысла их цитировать здесь.
^* Когда-то тоже прельстился этим методом, но после некоторой практики отказался от него и, боюсь, навсегда. В частности, для многопользовательской работы он мало подходит, ну разве только для полностью статических "деревьев".

Манго-Мангособственно Гугль на вопросы, подобные "сравнение Netsted и Adjacency List" (Материализованные пути... и т.д. в таком духе), выдаёт множество ссылок, следую по которым, можно прочетать, что Nested Sets всех даже очень и устраивают, если производить некие оптимизации (например, как сделал я, или же, например, такое извращение, как AL + NS ну и прочее).Могу только повторить: устраивает, ради Бога, никто Вам не запрещает. Я высказал своё частное мнение, подкреплённое собственной же практикой. Если желаете холливар, то это не ко мне. Гораздо полезнее, IMHO, поиграть со всеми методами хранения, включая типовые запросы, в том числе и модификации иерархии, с изучением статистики выполнения. Для меня это уже пройденный этап, выводы для себя я уже сделал.
Манго-Манго ChAP.S. IMHO, метод Nested Sets одним из самых неудачных способов реализации иерархических связей. Но это уже совсем другая тема.Скажите пожалуйсат, Вам известен "самый удачный" способ хранения (у управление разумеется - добавление, удаление и перемещение) иерархических структур в реляционных БД?
Если да, то поделитесь пожалуйста просто названием этого метода.Из "одним из самых неудачных способов" вовсе не следует, что есть "самый удачный". Мой личный выбор - разворачивание иерархии, т.е., хранение для каждого элемента всех его предков в отдельной таблице, для определенных задач - с указанием уровня. Запросы на получение всех предков или потомков узла можно получить простейшим запросом. При этом вовсе не исключаю, что в определённых ситуациях откажусь от него в пользу, например, построения полного пути("материализации"). Кроме того, в большинстве СУБД уже есть поддержка иерархические(рекурсивных) запросов, при небольшой глубине иерархии это тоже вполне вариант.