Ответ будет зависеть от того, что имеется ввиду под "работа с деревьями".
Если подразумевается работа в памяти с древовидными структурами, то в Аксе это ничем не отличатся от того, что описано во множестве учебников по программированию - те же структуры, позволяющие ссылаться на ветви дерева (или на вышестоящие уровни), те же принципы обхода дерева (независимо от того, на основе классов или переменных эти деревья построены.
Но, мне кажется, что под "работой с деревьями" подразумевается именно то, о чем ответил
mazzy, то есть, отображение данных из базы в форме (отчете) в виде дерева.
Как сказал
mazzy, обработка древовидных структур достаточно напряженная операция для реляционных данных. Тем не менее, бывает, что эти структуры приходится реализовывать. Дело в том, что достаточно много людей лучше воспринимают информацию именно в иерархическом виде, сверху вниз или снизу вверх (ну там всякие синтезы, анализы - кто в институтах изучал философию - помнит).
Поэтому, для того чтобы
скрестить ужа с ежом учесть потребности пользователей и ограничения реляционной модели можно придерживаться следующих правил (список не претендует на абсолютную истину, приведен просто по опыту, возможно не лучшему):
- Нет абсолютно всех удовлетворяющей иерархии.
Продажным девушкам отделу продаж нужна одна, закупщикам - другая, аналитикам - третья. При создании одной общей иерархии придется идти на кучу компромиссов.
- Если следовать принятой в Аксе кодировке (коды должны иметь "говорящие" значения), то обработка становится кошмаром. Для облегчения жизни программистов (и для быстродействия) приходится вводить альтернативную искусственную кодировку таким образом, чтобы по кодам была возможна фильтрация (выделено на скриншотах синим цветом) - например, поиск подчиненных значений при помощи конструкции "001*" . Это будет удобно программистам, а вот насколько это удобно пользователям? (хотя по моему опыту, через некоторое время пользователи запоминают кодировку и оперируют ей, а не названиями).
- Обязательно нужно предоставлять пользователям возможность переключаться между иерархическим и плоским представлением (на скриншотах выделено красным цветом). По моим наблюдениям у тех пользователей, которые не особенно разбираются в предметной области (а где набрать супер разбирающихся?), флаг иерархии включен, а у опытных выключен.
- Использовать уже то, что наработано в стандартной Аксе. Для отображения дерева есть несколько вариантов. Мне нравиться использовать классы - наследники CCFormTreeDatasource. Примеры можно посмотреть в классе HRMOrganizationTree и классах, начинающихся на KM, например KMActionTree, KMCollectionQuestionTree. Они используются в формах, которые можно найти либо при помощи перекрестных ссылок, либо поиском по приложению. Хотя, повторяю, это только один из вариантов.