2 berezdetsky, поделись своей моделькой думаю многим может пригодиться.
А про "сахар"... хм, да вообще весь КОП "ПрямойЗапрос" по сути сладкая примочка вокруг SQL и 1sqlite. Обертка позволяющая с некоторой долей вероятности писать универсальные запросы. Хотя эта универсальность рождает дополнительные вопросы и проблемы.
Что же касается ИТОГИ с поддержкой иерархии, над этим надо думать. Я еще не знаю каким путем пойти, если можно так выразиться. Тем более в мыслях есть еще дополнительные "опции" вроде периодичности (чтобы не плодить дополнительные колонки).

2 leshik, дык тогда "РезультатЗапроса" и "ВыборкаИзРезультатаЗапроса" может быть простой оберткой вокруг метода "Группировать" в целях обхода результата.
Кстати интересно было бы сравнить что получится если группировать и перебирать через КОП и через ИТЗ. Я думаю коп проиграет. 

2 JohnyDeath, кстати по похожим причинам нормального быстрого поиска в поставщике так и не реализовано 

Тут некоторый баг обнаружился в DBF работе. Связано с расчетом номера квартала. В итоге повлекло за собой функцию НачалоПериода и виртуальные таблицы Обороты с периодичностью квартал. Собственно не особо страшно просто 4,7,10 месяца попадали в предыдущие кварталы.
Ну и немного добавлено функционала.

1.05.015 от 14.03.10 г.
- Новая функция «КВАРТАЛ» и «МЕСЯЦСТРОКОЙ».
- Исправлена ошибка подготовки ВТ по оборотам (РегистрОбороты и РегистрОстаткиОбороты по регистру с типом остатки, БИОборотыДтКт, БИОбороты, БИОстаткиОбороты) с периодичностью КВАРТАЛ для DBF формата БД.
- Исправлена ошибка в функции НАЧАЛОПЕРИОДА(,КВАРТАЛ).

Я хотел бы высказать пару мыслей по оптимизации класса ПрямойЗапрос.
Я предлагаю в классе вызовы вида:

Для НомерЗначения = 0 По Вектор.Количество()-1 Цикл 

Заменить на

КолВоЗначенийВектора = Вектор.Количество()-1;
Для НомерЗначения = 0 По КолВоЗначенийВектора Цикл 

Также предлагаю вызовы вида:

Для НомерРесурса = 1 По МетаРегистр.Ресурс() Цикл 

Заменить на
Вариант 1.:

КолВоРесурсов = МетаРегистр.Ресурс();
Для НомерРесурса = 1 По  Цикл 

Вариант 2.: (это просто так фантазии).
получение данных о структуре метаданных регистров по индексированной таблице.
Вида:
НазваниеРегистра,ВидРеквизита(Измерение,Реквизит,Ресурс),Идентификатор
с индексом НазваниеРегистра+ВидРеквизита - я думаю ускорит построение запроса.
Все эти изменения связаны с вызовом инструкции определяющий конечный показатель счетчика при каждом проходе цикла.
Да и конечно же я готов произвести эти изменения в классе и выслать автору.
Можно для начала попробовать провести тестирование - только расскажите правильно методологию - как сравнить скорость построения запросов в том варианте что есть и в том варианте что я предлагаю.

Ну я честно говоря не замерял.
Вот смотри - при парсинге запроса (в основном ВТ в регистрах) каждый раз вызывается объект Метаданные и его методы Регистр(), Измерение(), Реквизит() - которые возвращают КОЛИЧЕСТВО объектов указанного вида в метаданных. А я предлагаю инициализировать эту структуру в индексированной таблице и реализовать получение данных не через объект Метаданные а через Индексированную таблицу.

vandalsvq писал(а) 26. Марта 2010 :: 19:11:

Я считаю что при инициализации класса. Я не думаю что это будет длительный процесс. Просто его не стоит делать при каждом парсинге запроса.
Цитата:

Я думаю что главное концептуальное согласие.

Цитата:

Согласен.

vandalsvq писал(а) 27. Марта 2010 :: 20:03:

Золотые слова.

Потратил таки немного времени на класс и могу вполне ответственно заявить, в построении запроса больше всего времени занимает не построение ВТ (причем какой бы сложности оно не было), соответственно работа с метаданными (вопреки моим мыслям) далеко не самое узкое место. Совсем я бы сказал не узкое.
Самые узкие места это:
1. Разбор и замена ключевых слов. Причем если их не много все равно их разбор и замена съедает как правило около 50% всего времени подготовки.
2. Разбор и замена функций запроса. Соответственно особенность такая же как и в п.1. Только доля около 20%.
3. Разбор и замена источников данных. Соответственно особенность такая же как в п.1. Только доля около 30-40%.
Не удивляйтесь что в сумме более 100%. ) это погрешности расчетов  .
Причем есть еще одна особенность, и связана она с тем как происходит подготовка запросов. Собственно говоря все что я напишу ниже является следствием моего неправильного подхода к построению класса.

Немного мыслей:
Изначально я считаю что самой глупой идеей было использование ключевых слов в русскоязычном написании. Ведь ничего сложного в том чтобы оставить селекты, фромы и прочее не было, а замене подлежал только синтаксис отличный от SQL. В таком случае все что надо было делать это привести один язык в соответствие с другим. И вот тут я жестко просчитался с самого начала. Собственно счас уже все является следствием этого просчета.
Разбор ключевых слов, функций и источников занимает как вы поняли около 70-80% времени. Причем если время растет это значение изменяется совершенно незначительно. Т.е. большой запрос = много времени, маленький = мало времени. Но доля всегда приблизительно равна.
И заключение: разбор текста происходит следующим образом:
- разбор всех ВТ (соответственно рост текста запроса очень большой)
- разбор всех особенных конструкций (первые, top/limit и пр.)
- разбор ключевых слов
- разбор функций
- разбор реквизитов и таблиц

Как это побороть? Я знаю, но время надо много.
Путь таков:
- перелопатить все ВТ чтобы там не было синтаксиса КОП-а
- изменить порядок обработки текста запроса, ВТ оставить на самый конец
- если не изменять порядок подготовки текста, тогда необходимо чтобы ВТ возвращались не готовым текстом а идентификаторами, и заменялись уже после реализации всей "пост"-обработки.

Вот так вот. Все эти записи - чтобы не забыть. А сделаю я это видимо к концу апреля.