Исключение неиспользуемых таблиц/пакетов из объединения.
Есть задание на отчёт из более чем 100 колонок.
Суть отчёта показать что оператор делал по контрагенту т.е. набор колонок:
ОператорКонтрагентВведеноДокументовИзмененийВведеноДокументовОтгрузки......СозданоЧегоНибудь |
Причём Операторов 10-20, контрагентов 10 000 – 80 000
Информацию я получаю пакетами в запросе (в Временые таблицы), всего получается 14 пакетов, соответственно 14 ВременныхТаблиц в каждой таблице есть Колонки “Оператор”,”Контрагент” ну и набор колонок для вывода в отчёт.
Первая проблема которая возникает как это всё объединить. Т.е. к какой таблице подключить каждую из 14 ВременыхТаблиц полученных в пакетах.
Понятно что не одна из 14 таблиц не может быть опорной таблицей.
Я решил эту проблему так: Сделал 15ю таблицу в которой через объединить собрал все 14 таблиц выбрав из них колонки Оператор, Контрагент и исключив из результата повторяющиеся записи.
Затем я присоединил к этой таблице остальные 14. И всё было бы хорошо если бы не вполне ожидаемое желание выводить не сразу 100 колонок а иметь возможность выбрать выводимые колонки.
Казалось бы ничего сложного объявляем таблицы как необязательные если поля не выбраны, таблицы не подключаются, конечно 14 пакетов не куда не денутся и время на формирование ВТ будет потрачено но это не является проблемой.
Собственно проблема:
Но тут всплывает та самая 15я опорная таблица если мы например оставили 5 полей из 100 то в отчёте будет огромное количество пустых строк т.к. в 15й таблице комбинация оператор/контрагент со всех 14 ВТ а данные по сути нам нужны только из 1 ВТ.
Как я понял компоновка данных не умеет убирать из объединения источники данных поля которых не используются.
Пока в голову приходит только в результирующем запросе в секции ГДЕ указать проверку 100 полей на NULL в виде:
Не Поле1 ЕСТЬ NUll или
Не Поле2 ЕСТЬ NUll или
Не Поле3 ЕСТЬ NUll
…..
Не Поле100 ЕСТЬ NUll
Ещё как вариант заставить СКД убирать пакеты в которых не используются выбранные поля, но тогда наверное придется в пакетах выбирать поля Оператор, Контрагент с другими именами (т.к. в отчёте эти поля всегда есть).
p.s. это копи паст с Mista, мне кажется здесь этот вопрос будет более актуален.
ух жесть какая. Не понимаю отчетов, в которых 100 колонок
Основная логика заказчика “Мы не когда не будем формировать 100 колонок, мы не знаем какой отчёт мы хотим, ты программист твоя задача сделать, а мы будем по ситуации выбирать необходимые колонки и таким образом один отчёт заменит нам много других отчётов”.
Но можно абстрагироваться от 100 колонок пусть будет например 15 колонок.
Основная суть:
Есть N наборов данных каждый из них имеет ключевое поле и n колонок данных.
Нужно все эти N отборов объединить и вывести в отчёт с использованием СКД, предоставив пользователю возможность отключать не используемые колонки.
Может проще будетв зависимости от настроек пользователя собрать запрос, выгрузить его в тз. А выводить уже средствами СКД?
Если подойдет: один набор данных – запрос к справочнику контрагентов. Другие наборы (один или больше) – получение данных для колонок отчета с разворотом по нужной аналитике. Настроить связи наборов. Тогда работать будет быстро (или быстрее, если и так быстро работает: делать запросы будет только к данным наборов и к нужной аналитике, которые требуются для выбранных колонок и аналитики). Настроить варианты отчетов с выводом нужных колонок. Главное – в каждом варианте настроить отбор “где колонка N 0”.
> Главное – в каждом варианте настроить отбор “где колонка N 0″.
Вообще не понял!
Работа с несколькими наборами – хороший вариант. Те наборы данных, из которых пользователь не использовал ни одного поля, не выбираются СКД из базы. Главная проблема – ЛЕВОЕ соединение наборов, т.е. необходим “опорный” набор, который будет левым по отношению ко ВСЕМ остальным. Как вариант – “усечённый” запрос с объединением из всех используемых источников. В нём достаточно выбирать только различные комбинации ключевых полей (Контрагент, Оператор, …). Без ресурсов он должен выполняться чуть быстрее. Возможно, что есть всё-таки таблица, содержащая полное множество комбинаций ключевых полей, тогда она станет “опорной”, возможно, что какие-то источники полностью перекрываются запросами из других – всё это пути к оптимизации. Но тут необходимо знание конкретной базы.
> Главное – в каждом варианте настроить отбор “где колонка N 0″.
Вообще не понял!
Сам не помню что имел в виду.
Про опорный набор – у коллеги вроде бы “Операторы” + “Контрагенты”