Ну и как концовка - в принципе имея абстрактный подход к хранению и обработке данных, на SQL можно очень многое реализовать, причем частенько решения будут менее трудоемки в коде и обгонять по скорости решения, аналогично реализованные на алгоритмических языках (например с вышеуказанной моделью хранения деревьев я спокойненько могу срезать с дерева одним запросом все уровни, удовлетворяющие какому то условию, на алгоритмических языках придется писать код, пользоваться рекурсией и т.д.). Не спорю, что приятней, когда SQL сам может обрабатывать иеархии, но в принципе у многих СУБД рекурсивные запросы уже есть, в следующей версии MSSQL я тоже слышал они появятся, что уже говорит о неком новом стандарте в SQL, думаю и ASA подтянется до своих больших братьев-конкурентов СУБД.

xtony
Разворачивать таблицы и генерить кросстабы на SQL сложно, но можно. Решения опять же в интернете выложены. Самое очевидное, что без динамического SQL не обойтись. Дальше зависит от самих возможностей СУБД. У меня пока такой задачи не стояло, так как кросстабы требовались в основном в отчетах и тот же Crystal Report или Power Builder прекрасно с этим справляются сами. Однако чисто теоретически, если такая задача потребуется, то в Sybase ASA я наверное попробую покопать в сторону агрегатной функции List, которая группирует данные в виде списка с разделителем, т.е. следующий скрипт:

на выходе вернет примерно следующее:

Далее по размышлении если применить CROSS JOIN и воспользоваться возможностью ASA этот select на выходе закатать в текстовый файл с разделителеми, создать через динамический sql соотвествующую структуру темповой таблицы, то можно по идее через оператор WatcomSQL Load этот файл считать в таблицу "легким движением руки". Думаю такой метод сработает быстрее, чем пытаться данные заполнять в темповую таблицу через динамический SQL. Сам такого не пробовал, но как говорится, копать есть куда :)

Ну это смотря какая СУБД использоваться будет. Если это для Sybase ASE, то в дурку ты гораздо раньше попадешь :) Но я так понимаю это для MSSQL 2000 и твоей задачи, так что тут вообще то все от тебя зависит, возможно есть шанс перепроектировать постановку так, чтобы задача выглядела более легко под релляционные модели данных.

c127
Спасибо за переформулировку мой действительно неудачно выраженной мысли. Дело в том, что я примерно знаю, о чем пишет xtony - задача у него не из легких - расчеты потребления теплоэнергии абонентами, где существует сложное дерево подключение абонентов к теплосетям. Первое что действительно приходит на ум любому ООП программисту - считать все это дело графами. И тут конечно SQL уже не в помощь. Однако работая раньше в РАО я видел аналогичную задачу - расчет потребления электроэнергии, которую в бытность во времена Союза один программист решил без всяких графов. Работала она и на старых совестких машинах, работает прекрасно и сейчас на ДОСовом Foxpro. Не знаю как это уж назвать по научному, но расчет велся поэтажно, т.е. разом по каждому уровню глубины подключений. Это было возможно, так как следующий узел-абонент всегда зависел от показаний предыдущего узла-абонента и например самый последний уровень подключения никак не зависел в расчетах от корня. Кстати такая методика расчета прекрасно "перекладывается" на SQL, это я и имел ввиду.

Sjfx
Думаю PL99 развеял Ваши сомнения в ASA. Как меня самого не удивляет, но для сервера рабочих групп ASA слишком много всего умеет. Радует, что в отличие от MSSQL он достаточно гибок, не требователен к ресурсам и в тоже время обладает всеми качествами современного SQL сервера (развитый SQL, нормальные средства администрирования, отладка, мощный оптимизатор запросов, графический план запросов, репликация, кроссплатформенность, решения для мобильных устройств, криптография БД, поддержка работы с сжатыми БД и т.д.). С учетом того, что ASA в непрерывном развитии и даже в периодически выходящих паках не только ошибки четко и быстро исправляются, но и он обрастает новым функционалом без смены версии, лично я считаю что для задач среднего обьема (учет, бухгалтерия и т.д.) ASA гораздо приятней и удачней, чем MSSQL. Но повторюсь это мое личное мнение, так что ничего страшного против MSSQL я не говорил :)