pitersky, я прочел эту фразу
Просто упомянутое решение про хранение всего комплекса служебных join'ов для решения проблемы производительности как-то таковым не особо выглядит. При упомянутых режимах обновления этой сервисной информации - только при perSession ситуация выглядит более-менее, а perExecution вообще лишает смысла хранение это инфы(если каждый раз при исполнении запроса пересчитывать эту инфу - то зачем ее хранить ?). Но и даже выглядящий более-менее режим обновления раз в сессию тоже может не оказаться панацеей, когда каждый пользователь при первом открытии в сессии любой формы будет N-нное время ждать перестройки этих данных. Каковым будет это N-нное время - зависит от реализации. Если делали "универсальную шнягу" ( (c) by mazzy
), то задача поиска связи м-ду двумя заранее неизвестными таблицами, не имеющими прямой связи друг с другом, через N промежуточных таблиц может очень хорошо "выстрелить", потому как в таком поиске по прямым связям (через Relations) и косвенным (через EDT полей) будет огромное количество "холостых" и бесполезных итераций и ветвлений поиска. Сей факт как раз и вызывает сомнение про решенность проблем производительности. Хотя, если помнить,что в 6-ке AOS хотят в БД запихать - может и оно и не так будет тормозить.
В общем, будем посмотреть - сейчас можно только гадать ...