Метод "Группировать". Хотелось бы добавить возможность скрывать отдельные колонки таблицы на разных уровнях группировки, т.к. не на каждом уровне нужна информация из всех колонок. Это приведёт к экономии памяти и ускорению работы.

Пример:
В SQL запросе я получаю следующую информацию, сохраняю в ИТ:
Товар - объект БД для расшифровки ячейки,
Товар_Родитель - объект БД для быстрой группировки по группам справочника,
Товар_Артикул - строка, артикул товара,
Товар_Представление - строка, название товара,
Товар_Единица_Представление - строка, название единицы измерения,
Склад -  объект БД для расшифровки ячейки,
Склад_Родитель - объект БД для быстрой группировки по группам справочника,
Склад_Представление - строка, название склада,
ОстатокТовараПриход,
ОстатокТовараРасход.

Далее я группирую ИТ:
Группировать("Товар: &Товар;Склад: &Склад","ОстатокТовараПриход,ОстатокТовараРасход");
При этом в каждой строке каждой таблицы есть все колонки, как и до группировки. Хотя когда я вывожу, например, группировку "Склад", меня не интересует информация о названии, артикуле и ед. изм. товара. Также мне в отчете не нужны колонки "Склад_Родитель","Товар_Родитель".
Я смотрел расход памяти при большом количестве строк, возвращаемых запросом. Так при 60к строк и объёмом возвращаемых данных ~15Мб после группировки 1С начала использовать ~1.4 Гб оперативной памяти.

varelchik писал(а) 05. Октября 2006 :: 05:11:

Я то подумал. Я говорю про экономию памяти. У меня в отчете пользователь может выбрать группировки по 3-м измерениям регистра + по документу. Измерения регистра - справочники, у одного уровень вложенности 10, у другого 6, у третьего 5.
А теперь подумай, сколько будет использоваться памяти если юзер захочет вывести отчет по всем группировкам и в каждой группировке захочет видеть итоги по группе.

А XML-сериализацию ИТ с вложенными ИТ и составными типами (элемент справочника, документ) хорошы бы иметь (мечты, мечты....) 

Ни к чему это всё. По трём причинам.
1) Метод Группировать() - отстойный метод. Слишком медленный. Я лично им не пользуюсь, и никому не рекомендую.
2) Если ты данные получаешь прямым запросом, то сам бог велел сделать всё там.
3) Реализация данной фичи только запутает синтаксис метода, а реальной выгоды на самом деле практически не будет, потому как в процессе группировки память всё равно сожрётся, потому что все колонки нужно держать в памяти до последнего, и только после завершения группировки их можно удалять.

Самая правильная альтернатива - считать всё в запросе.
Ещё вариант - считать итоги при выводе на печать.

Ускорить группировку в рамках ИТ по видимому принципиально невозможно, потому как основное время уходит на построение индексов. И как ни ускоряй этот процесс, в итоге всё равно получается неэффективно.

Посмотри пример, там есть и получение групп в SQL запросе и подсчет итогов при выводе отчета

tav13 писал(а) 06. Октября 2006 :: 07:42:


Спасибо, но я бы хотел чтобы итоги по группам посчитал SQL сервер оператором WITH ROLLUP. Есть идеи?

Valar писал(а) 06. Октября 2006 :: 08:00:

Есть...Используй ROLLUP
Хороший совет: Есть внешняя обработка для 1С под названием QA (см. вложение). Пойди от простого к сложному, напиши в ней запрос с получением нужных остатков, потом добавь ROLLUP, посмотри что будет получатся....и т.д. и т.п.
P.S.
Спасибо за QA - DmitrO