В одном из предыдущих сообщений нашел Ваше.

Есть некоторый иерархический рубрикатор. Сделан стандартно, в одной таблице, следующей структуры
ID NAME PARENT_ID LEVEL ORDER PATH
1 'Рубрика 1' NULL 1 1 '0001'
2 'Рубрика 1.1' 1 2 1 '0001 0001'
3 'Рубрика 1.1.1' 2 3 1 '0001 0001 0001'
4 'Рубрика 1.1.2' 2 3 2 '0001 0001 0002'
5 'Рубрика 1.2' 1 2 2 '0001 0002'
6 'Рубрика 1.3' 1 2 3 '0001 0003'
Поле ORDER - порядок следования элементов с общим родителем в пределах одного уровня.
Поле PATH используется для выборки раскрытого дерева одним запросом (сортировка по нему дает упорядоченное дерево, где дети находятся точно под своими родителями, остается только при выводе сдвинуть их вправо на значение поля LEVEL)
Теперь же добавилась задача двигать элементы c общим родителем относительно друг друга (вверх-вниз)
Чтобы сохранить нормальную функциональность поля PATH, в этом случае после сдвижки нужно производить глобальный апдейт поля PATH для всех детей двух меняющихся местами элементов, что не очень нравится. Есть какие-либо другие решения для организации иерархий с динамическим порядком следования внутри уровня, не требующие подобных телодвижений? Чтобы оставалась возможность выбирать выстроенное дерево одним запросом и не осуществлять множественных апдейтов при изменении положения элементов?
Кстати, та же проблема встает и при редактировании иерархии - перемещении одних разделов в другие.

Я использую подобную структуру для хранения объектов по иерархической связи.
Не совсем понял зачем у вас есть поле Parent_ID, если есть поле Path, из которого и можно взять информацию о родителе? Вот для неирахических связей между объектами (входимость, применяемость и т.д.), я как раз пользую струтуру ParentID, ChildID.

Опять же непонятно зачем поле Level, если эту информацию опять же можно взять из Path?

Опять же непонятно зачем апдейтить PATH при изменении порядка следования дочерних объектов внутри одного родителя, если у Вас есть "Поле ORDER - порядок следования элементов с общим родителем в пределах одного уровня." Ну и меняйте это поле и запрос делайте с сортировкой по этому полю. Может я че нить не понимаю в словах "обеспечить нормальную функциональность поля Path"? Лично я это поле как раз и использую для:
1)Определения родителя
2)Определения Levelа
3)Создания иерархической структуры, из которой одним запросом можно допустим достать всех (или до определенного уровня) дочерних объектов или наоборот родительских.
4)Облегчаю функциональность наследования атрибутов дочерними объектами атрибутов родительских объектов.

И какая такая функциональность нужна, чтобы при перемещении объектов внутри родителя, обязательно соблюдать порядок в поле Path хоть убей не понимаю???
У меня к такой таблице с объектами как у Вас с категориями (кстати я просто сделал еще одно поле в этой таблице, которое и определяет что это: категория, экземпляр объекта или его вариант) привязана таблица с характеристиками (у меня это объекты с любым набором атрибутов: наименование, обозначение, описание, длина, высота и др.), куда я и наименование тоже запихал. И сортировка у меня идет по значениям тех характеристик, которые указал пользователь.

Потом действительно ли необходимо Вам выводить сразу все дерево?
Я например делаю так: Вывожу root дерева, потом по нажатию на "+" считываю информацию о сортировке внутри родителя и наборе характеристик, которые нужно отобразить в дочерних объектах и делаю динамический запрос, который выбирает дочерние объекты в нужном порядке сортировке с нужными характеристиками. И так спускаюсь по всему дереву.

Кстати ORDER - это тоже характеристика. Если пользователь (администратор) вдруг хочет, чтобы сортировка шла не по значениям каких-то характеристик, а по его алгоритму, который он хранит у себя в голове и никому не рассказывает (трудно представить такой случай, голова - не компьютер, все равно забудет и чей то он их так расставил), то он для каждого объекта может указать значение этой характеристики и поставить, чтобы в рубрике "Книги А.С. Пушкина" ему выводились книги в порядке соответствия со значением этой самой характеристики Order, а значения эти например обозначают порядок, в котором эти книги он дарил своим любовницам (во я придумал !).

Считывать сразу все дерево - это противоречит всем законам клиент-серверной архитектуры и пользователь просто устанет кофе пить, если я ему сразу все дерево из 100 000 объектов (это наш номенклатурный справочник) считывать буду. А мы всего навсего небольшая производственная контора, которая сравнительно немного изделий выпукает. А если взять какой-нибудь крупный завод или другие крупные задачи классификации.

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

Удачи всем.

Не понял вопрос. Какие сложности? В запросе? В построении дерева?
Какая связь между "считать все дерево" и "в дереве найти все узлы, обладающие некоторым свойством"? Вы хотите задать условия фильтрации дерева? Т.е открыть (оставить) ветки с объектами, удовлетворяющими некоторым условиям? Вы что при этом сначала считываете все дерево, потом по нему пробегаетесь и оставляете только те узлы, которые отвечают заданным условиям? Или как?
Я вообще то делаю так: пользователь задает условия для поиска объектов, я делаю запрос по этим условиям и сливаю результат ему просто в список, далее если пользователь хочет посмотреть где в дереве находится данный конкретный объект, он жмет по нему и я строю (раскрываю) ветку, в которой находится этот объект.
Или если сильно надо, то можно и дерево отфильтровать, но опять же для этого не надо считывать его все. Делаете запрос, который вам оставляет только то, что нужно и строите по нему дерево.
Опять же я не отрицал возможности считать все дерево сразу (объясните все-таки какая связь между считыванием всего дерева и поиском узлов по конкретным условиям), просто я спросил зачем в предложенной структуре некоторые дополнительные поля (Level, Parent_ID), которые дублируют функциональность поля Path (может они как-то оптимизируют запросы) и зачем при изменении порядка следования дочерних объектов в одном родителе делать UPDATE поля Path, чтобы привести его в соответствии с порядком следования.