Исключение неиспользуемых таблиц/пакетов из объединения.

Отзывов (6)FavoriteLoadingВ закладки

Есть задание на отчёт из более чем 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, мне кажется здесь этот вопрос будет более актуален.

google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

6 Коммент.

  1. Основная логика заказчика “Мы не когда не будем формировать 100 колонок, мы не знаем какой отчёт мы хотим, ты программист твоя задача сделать, а мы будем по ситуации выбирать необходимые колонки и таким образом один отчёт заменит нам много других отчётов”.

    Но можно абстрагироваться от 100 колонок пусть будет например 15 колонок.
    Основная суть:
    Есть N наборов данных каждый из них имеет ключевое поле и n колонок данных.

    Нужно все эти N отборов объединить и вывести в отчёт с использованием СКД, предоставив пользователю возможность отключать не используемые колонки.

    • Может проще будетв зависимости от настроек пользователя собрать запрос, выгрузить его в тз. А выводить уже средствами СКД?

  2. Если подойдет: один набор данных – запрос к справочнику контрагентов. Другие наборы (один или больше) – получение данных для колонок отчета с разворотом по нужной аналитике. Настроить связи наборов. Тогда работать будет быстро (или быстрее, если и так быстро работает: делать запросы будет только к данным наборов и к нужной аналитике, которые требуются для выбранных колонок и аналитики). Настроить варианты отчетов с выводом нужных колонок. Главное – в каждом варианте настроить отбор “где колонка N 0”.

  3. > Главное – в каждом варианте настроить отбор “где колонка N 0″.
    Вообще не понял!
    Работа с несколькими наборами – хороший вариант. Те наборы данных, из которых пользователь не использовал ни одного поля, не выбираются СКД из базы. Главная проблема – ЛЕВОЕ соединение наборов, т.е. необходим “опорный” набор, который будет левым по отношению ко ВСЕМ остальным. Как вариант – “усечённый” запрос с объединением из всех используемых источников. В нём достаточно выбирать только различные комбинации ключевых полей (Контрагент, Оператор, …). Без ресурсов он должен выполняться чуть быстрее. Возможно, что есть всё-таки таблица, содержащая полное множество комбинаций ключевых полей, тогда она станет “опорной”, возможно, что какие-то источники полностью перекрываются запросами из других – всё это пути к оптимизации. Но тут необходимо знание конкретной базы.

  4. > Главное – в каждом варианте настроить отбор “где колонка N 0″.
    Вообще не понял!

    Сам не помню что имел в виду.
    Про опорный набор – у коллеги вроде бы “Операторы” + “Контрагенты”

Оставить комментарий

RSSКомментарии в RSS

Авторизация

Логин:
Пароль:
Регистрация

Архивы

Закладки

  • Your favorites will be here.