Готовишься к экзамену?
Полнофункциональный тренажер @bot_1cnik_bot с полноценным обучением, режимом экзамена и подробной статистикой.
Как правильно задавать запрос для набора данных типа «Запрос» в Системе компоновки данных, если конечный состав колонок отчета зависит от настроек пользователя?
Указать в запросе только необходимые (потенциально используемые) поля и их псевдонимы, а итоговый запрос система сформирует динамически по выбранным настройкам.
Правильно: В СКД разработчик задает перечень доступных полей (те, которые могут понадобиться для вывода, группировок, отборов, сортировок и итогов), а конкретный состав выбирается настройками компоновки. Поэтому фактически исполняемый запрос формируется системой на лету и может отличаться в зависимости от того, какие поля реально используются в варианте отчета.
Достаточно перечислить только таблицы-источники, а поля можно не определять - система «додумает» их сама.
Неправильно: СКД не может корректно построить отчет без явного описания полей, потому что именно поля становятся доступными для вывода, отборов, группировок и ресурсов. Если поля не определены (или определены неполно/без псевдонимов), пользовательские настройки и построение итогового запроса будут ограничены или приведут к ошибкам.
Запрос нужно прописывать полностью заранее как окончательный (статический) - таким, каким он будет выполняться всегда.
Неправильно: В СКД итоговый текст запроса обычно меняется в зависимости от настроек компоновки: выбранных полей, группировок, отборов и сортировок. Если попытаться «застолбить» статический окончательный запрос, вы лишите отчет гибкости и получите лишние поля/соединения, которые пользователю могут быть не нужны.
Пояснение
В СКД запрос набора данных - это не «финальный SQL навсегда», а заготовка, из которой система собирает исполняемый запрос под текущие настройки отчета. На практике это означает:
1) В тексте запроса описывайте поля, которые могут понадобиться: для вывода в колонках, для группировок, для сортировки, для отборов и для расчета ресурсов/итогов. Эти поля должны иметь стабильные псевдонимы (через «КАК ...»), чтобы на них могли ссылаться элементы схемы компоновки и настройки пользователя.
2) Конечный состав выбирается настройками. Например, если в варианте отчета пользователь отключил колонку «Склад» и не использует отбор по складу, система может сформировать итоговый запрос без этого поля (и иногда даже без лишних соединений), потому что оно не участвует в компоновке результата.
3) Типовой сценарий: вы делаете отчет «Продажи». В запросе есть поля «Номенклатура», «Контрагент», «Склад», «Количество», «Сумма». Пользователь создает вариант, где выводит только «Номенклатура» и «Сумма» и группирует по номенклатуре - исполняемый запрос будет ориентирован на эти выбранные поля и группировку.
4) Полезные рекомендации:
- Не рассчитывайте на «само появится»: если поле должно быть доступно пользователю для выбора/отбора, оно должно быть корректно определено в наборе данных.
- Следите за именами и типами полей (особенно для вычисляемых выражений), чтобы отборы и итоги работали предсказуемо.
- Заранее продумывайте поля «для служебных нужд» (например, ссылка на объект, период, ключи для связей), даже если они не выводятся на экран - они могут понадобиться для отборов, группировок или связей наборов данных.