Заметки про запросы. Коллекция

06.12.2019 63 Comments

Практика программирования, Разработка

Кто-то коллекционирует марки, а я собрал мини-коллекцию запросов, хотел с Вами поделиться.
Надеюсь, что мои комментарии представляют отдельную ценность.

Последние неоплаченные накладные.

По заданной &CуммаЗадолженности найти последний неоплаченный документ. Для такого документа сумма всех последующих документов меньше &CуммаЗадолженности, а сумма всех последующих документов вместе с его суммой – больше &CуммаЗадолженности. Сумму накладных лучше брать из регистра взаиморасчетов. Возможен отбор по контрагенту. Поле «Момент времени» умышленно не включил в условия соединения. Для приемлемого быстродействия запрос Таб1 обязательно нужно ограничивать по количеству «Первые ХХ» или задать период выборки. 

ВЫБРАТЬ ПЕРВЫЕ ХХ
РеализацияТоваровУслуг.Дата КАК ДатаРТУ,
РеализацияТоваровУслуг.Ссылка КАК СсылкаРТУ,
РеализацияТоваровУслуг.СуммаДокумента,
РеализацияТоваровУслуг.МоментВремени
ПОМЕСТИТЬ Таб1
ИЗ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
УПОРЯДОЧИТЬ ПО ДатаРТУ УБЫВ
ИНДЕКСИРОВАТЬ ПО ДатаРТУ
;
ВЫБРАТЬ
Таб1.СсылкаРТУ
ИЗ Таб1 КАК Таб1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таб1 КАК Таб11
ПО Таб1.ДатаРТУ <= Таб11.ДатаРТУ
ГДЕ Таб1.МоментВремени < Таб11.МоментВремени
СГРУППИРОВАТЬ ПО Таб1.СсылкаРТУ
ИМЕЮЩИЕ СУММА(Таб11.СуммаДокумента) < &CуммаЗадолженности
И МАКСИМУМ(Таб1.СуммаДокумента) + СУММА(Таб11.СуммаДокумента) >= &CуммаЗадолженности

В обсуждении статьи //infostart.ru/public/568299/ подборка ссылок про отчеты по просроченной задолженности

//infostart.ru/public/20221/

//infostart.ru/public/58966/

//infostart.ru/public/61295/

//infostart.ru/public/62899/

//infostart.ru/public/68225/

//infostart.ru/public/88999/

//infostart.ru/public/122548/

Аналог среза последних

Можно применять для непериодичных регистров, для которых нет совпадения поля «период» по одинаковым измерениям для разных записей регистра или такими совпадениями можно пренебречь. Похожие рассуждения в статье //infostart.ru/public/140933. Только не написано про возможные ошибки, когда периоды совпадают: в статье такая задача не ставилась.

ВЫБРАТЬ
РаботникиОрганизаций.Сотрудник КАК Сотрудник,
МАКСИМУМ(РаботникиОрганизаций.Период) КАК Период
ПОМЕСТИТЬ Таб1
ИЗ РегистрСведений.РаботникиОрганизаций КАК РаботникиОрганизаций
СГРУППИРОВАТЬ ПО РаботникиОрганизаций.Сотрудник
ИНДЕКСИРОВАТЬ ПО Сотрудник, Период
;
ВЫБРАТЬ
Работники.*
ИЗ Таб1 КАК Таб1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.РаботникиОрганизаций КАК Работники
ПО Таб1.Сотрудник = Работники.Сотрудник
И Таб1.Период = Работники.Период

Записи с повторением выбранного поля.

Например, запрос возвращает повторяющиеся значения ИНН из справочника Контрагенты. Применяется группирование по текстовому полю ИНН. Одно время я думал, что так можно делать только по полю ссылочного типа. ))

ВЫБРАТЬ
Контрагенты.ИНН КАК ИНН,
КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Контрагенты.Ссылка) КАК Ссылка
ИЗ Справочник.Контрагенты КАК Контрагенты
СГРУППИРОВАТЬ ПО Контрагенты.ИНН
ИМЕЮЩИЕ КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Контрагенты.Ссылка) > 1

Похожая задача решается через внутреннее соединение //infostart.ru/public/535198

Заменить полное (левое) Соединение на Объединение.

При соединении двух таблиц, могут появляться повторяющиеся записи. Например, в этом случае ключ соединения Номенклатура – Серии Номенклатуры не может быть уникальным из-за измерения «ДокументОприходования». В некоторых случаях это можно устранить с помощью объединения. По тексту запроса есть крупинки полезных ископаемых:

  • Применяется редкий синтаксис проверки вхождения (Номенклатура, СерияНоменклатуры) В  (ВЫБРАТЬ ….)
  • К полю «ДокументОприходования» сначала применяем «Выразить», получаем тип Null или Документ.ПоступлениеТоваровУслуг, затем вычисляем Максимум. В результате получаем одно из поступлений.
  • При объединении двух таблиц в числовое поле лучше ставить 0, если поле планируем суммировать и Null, если будет функция Максимум (Минимум)
  • Команда ОБЪЕДИНИТЬ ВСЕ не отбрасывает повторения, как команда ОБЪЕДИНИТЬ
  • Параметр «Дата» виртуальной таблицы лучше заполнять: иначе SQL вынужден делать дополнительный запрос для его определения.
  • Используются Индексы. Для регистра «ТоварыНаСкладах» первое измерение – склад, поэтому индекс не так полезен, как для регистра «ПартииТоваровНаСкладахБУ»
  • Самый важный момент: в условия виртуальной таблицы не рекомендуется вставлять сложные условия. Их все нужно проверять раньше во временной таблице или даже позже, в секции «ГДЕ» запроса, содержащего виртуальные таблицы. Более подробно статья«Использование параметра Условие при обращении к ВТ» https://its.1c.ru/db/metod8dev/content/5457 .
ВЫБРАТЬ РАЗЛИЧНЫЕ
СерииНоменклатуры.Владелец КАК Номенклатура,
СерииНоменклатуры.Ссылка КАК Серия
ПОМЕСТИТЬ табТовары
ИЗ Справочник.СерииНоменклатуры КАК СерииНоменклатуры
ГДЕ &РазныеСложныеУсловия
И СерииНоменклатуры.Владелец В ИЕРАРХИИ(&Номенклатура)
ИНДЕКСИРОВАТЬ ПО Серия, Номенклатура
;
ВЫБРАТЬ
Партии.Номенклатура КАК Номенклатура,
Партии.Склад КАК Склад,
ВЫРАЗИТЬ(Партии.ДокументОприходования КАК Документ.ПоступлениеТоваровУслуг) КАК ДокументОприходования,
Партии.КоличествоОстаток КАК КоличествоПартии,
Партии.СтоимостьОстаток КАК СтоимостьПартии,
0 КАК КоличествоОстаток
ПОМЕСТИТЬ табОстатки
ИЗ РегистрНакопления.ПартииТоваровНаСкладахБухгалтерскийУчет.Остатки(&ДатаОстатков,
(Номенклатура, СерияНоменклатуры) В
(ВЫБРАТЬ
табТовары.Номенклатура,
табТовары.Серия
ИЗ табТовары КАК табТовары)) КАК Партии

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
Остатки.Номенклатура,
Остатки.Склад,
NULL,
0,
0,
Остатки.КоличествоОстаток
ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(&ДатаОстатков,
(Номенклатура, СерияНоменклатуры) В
(ВЫБРАТЬ
табТовары.Номенклатура,
табТовары.Серия
ИЗ
табТовары КАК табТовары)) КАК Остатки
ИНДЕКСИРОВАТЬ ПО Склад, ДокументОприходования, Номенклатура
;
ВЫБРАТЬ
Таб1.Номенклатура,
Таб1.Склад,
МАКСИМУМ(Таб1.ДокументОприходования) КАК ДокументОприходования,
СУММА(Таб1.КоличествоПартии) КАК КоличествоПартии,
СУММА(Таб1.СтоимостьПартии) КАК СтоимостьПартии,
СУММА(Таб1.КоличествоОстаток) КАК КоличествоОстаток
ИЗ табОстатки КАК Таб1
СГРУППИРОВАТЬ ПО Таб1.Номенклатура, Таб1.Склад

Вывести нумерованный список справочника с помощью запроса, если есть только наименование, нет кода.

Эта задача встретилась мне на одном из собеседований, несколько лет назад. Решение ниже. Спасибо DonPedroGonsales (saudin) за замеченную опечатку. Спасибо Дмитрий Кондаков (dnkon) за более быстрый код.

ВЫБРАТЬ
Справочник.Ссылка КАК Ссылка,
1 КАК Нумератор
ПОМЕСТИТЬ Таб1
ИЗ Справочник.Справочник КАК Справочник
Индексировать по Ссылка
;
////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
Таб1.Ссылка,
СУММА(Таб1.Нумератор) КАК Нумератор
ИЗ Таб1 КАК Таб1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таб1 КАК Таб11
ПО Таб1.Ссылка <= Таб11.Ссылка
СГРУППИРОВАТЬ ПО Таб1.Ссылка
УПОРЯДОЧИТЬ ПО Нумератор

Горизонтальное масштабирование

Смотрите подробнее //infostart.ru/public/535198/. В запросе используется интересная конструкция, выбирающая данные из середины таблицы.

ВЫБРАТЬ ПЕРВЫЕ 10000
Контрагенты.Ссылка КАК Ссылка
ПОМЕСТИТЬ Первые1000
ИЗ Справочник.Контрагенты КАК Контрагенты
;
ВЫБРАТЬ ПЕРВЫЕ 1000
Первые1000.Ссылка КАК Ссылка
ИЗ Первые1000 КАК Первые1000
УПОРЯДОЧИТЬ ПО Ссылка УБЫВ

"Неожиданные" результаты обработки NULL

Агрегатные функции корректно обрабатывают Null. В выборке Поле1 = 2.

ВЫБРАТЬ
2 КАК Поле1
ПОМЕСТИТЬ Таб1
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
NULL
;
ВЫБРАТЬ
СУММА(Таб1.Поле1) КАК Поле1
ИЗ
Таб1 КАК Таб1

Равенство здесь не применимо. В выборке Поле1 = Ложь, остальные — Null. 

ВЫБРАТЬ
ВЫБОР КОГДА NULL = NULL
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ КАК Поле1,
ВЫРАЗИТЬ(NULL КАК СТРОКА(5)) КАК Поле2,
МАКСИМУМ(NULL) КАК Поле3,
СУММА(NULL) КАК Поле4

В выборке Поле1 = Null. Спасибо Maxim Kolkin (the1).

ВЫБРАТЬ
0 + NULL КАК Поле1

Кстати, источником Null могут служить

  • левое, правое, полное соединение (кроме внутреннего),
  • Арифметические, агрегатные, прочие действия над типом Null
  • Неполные, не учитывающие все возможные условия логические выражения, например Выбор Если Тогда Конец (без Иначе)

Используем в запросе Таблицу Значений как параметр.

Кстати, встречался с ситуацией, когда условие "Где" ниже строки "ИЗ &ТаблЧастьПарам КАК ТаблЧасть1" не работает

//1. Создаем в конструкторе запрос.
"ВЫБРАТЬ
| ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) КАК Номенклатура,
| ЗНАЧЕНИЕ(Справочник.СерииНОменклатуры.ПустаяСсылка) КАК СерияНоменклатуры,
| ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка) КАК Склад,
| 0 КАК Количество
|ПОМЕСТИТЬ ТаблЧасть
|;
|
|////////////////////////////////
|ВЫБРАТЬ
| ТоварыНаСкладахОстатки.Склад,
| ТоварыНаСкладахОстатки.Номенклатура,
| ТоварыНаСкладахОстатки.СерияНоменклатуры,
| СУММА(ТоварыНаСкладахОстатки.КоличествоОстаток) КАК КоличествоОстаток
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки(
|   &ДатаОстатков,
|   (Номенклатура, СерияНоменклатуры, Склад) В
|    (ВЫБРАТЬ
|     ТаблЧасть.Номенклатура,
|     ТаблЧасть.СерияНоменклатуры,
|     ТаблЧасть.Склад
|    ИЗ
|     ТаблЧасть КАК ТаблЧасть)) КАК ТоварыНаСкладахОстатки
|
|СГРУППИРОВАТЬ ПО
| ТоварыНаСкладахОстатки.Склад,
| ТоварыНаСкладахОстатки.Номенклатура,
| ТоварыНаСкладахОстатки.СерияНоменклатуры"

//2. По первой таблице запроса создаем типизированную Таблицу Значений без строк. Обратите внимание на условие ГДЕ ЛОЖЬ.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) КАК Номенклатура,
| ЗНАЧЕНИЕ(Справочник.СерииНоменклатуры.ПустаяСсылка) КАК СерияНоменклатуры,
| ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка) КАК Склад,
| 0 КАК Количество
|ГДЕ
| ЛОЖЬ";

ТаблЧасть = Запрос.Выполнить().Выгрузить();

//3. Обработка таблицы значений
// Стр = ТаблЧасть.ДобавитьСтроку();
// ТаблЧасть.Свернуть("Номенклатура,СерияНоменклатуры,Склад","Количество");

//4. В запросе переделываем первую таблицу под использование Таблицы Значений как параметра. Не забудьте сделать группировку.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ТаблЧасть1.Номенклатура,
| ТаблЧасть1.СерияНоменклатуры,
| ТаблЧасть1.Склад,
| ТаблЧасть1.Количество
|ПОМЕСТИТЬ ТаблЧасть
|ИЗ
| &ТаблЧастьПарам КАК ТаблЧасть1
|;
|
|////////////////////////////////
|ВЫБРАТЬ
| ТоварыНаСкладахОстатки.Склад,
| ТоварыНаСкладахОстатки.Номенклатура,
| ТоварыНаСкладахОстатки.СерияНоменклатуры,
| СУММА(ТоварыНаСкладахОстатки.КоличествоОстаток) КАК КоличествоОстаток
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки(
|   &ДатаОстатков,
|   (Номенклатура, СерияНоменклатуры, Склад) В
|    (ВЫБРАТЬ
|     ТаблЧасть.Номенклатура,
|     ТаблЧасть.СерияНоменклатуры,
|     ТаблЧасть.Склад
|    ИЗ
|     ТаблЧасть КАК ТаблЧасть)) КАК ТоварыНаСкладахОстатки
|
|СГРУППИРОВАТЬ ПО
| ТоварыНаСкладахОстатки.Склад,
| ТоварыНаСкладахОстатки.Номенклатура,
| ТоварыНаСкладахОстатки.СерияНоменклатуры"

Запрос.УстановитьПараметр("ТаблЧастьПарам",ТаблЧасть);
Запрос.УстановитьПараметр("ДатаОстатков",);

Используем запрос в цикле, с передачей информации внутрь цикла.

МВТ1 = Новый МенеджерВременныхТаблиц;
ЗапросОбщий = Новый Запрос;
ЗапросОбщий.МенеджерВременныхТаблиц = МВТ1;
ЗапросОбщий.Текст =
"ВЫБРАТЬ
| 1 КАК Поле1
|ПОМЕСТИТЬ ОбщаяВТ";
Результат = ЗапросОбщий.Выполнить();
//Создаем запрос, рассчитываем временную таблицу, общую для всех запросов внутри цикла, передаем ее через Менеджер временных таблиц.

Для КК = 1 ПО 10 Цикл
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МВТ1;
Запрос.Текст =
"ВЫБРАТЬ
|3 КАК Поле1
|ПОМЕСТИТЬ ЧастнаяВТ
|;
|ВЫБРАТЬ
|ОбщаяВТ.Поле1,
|ЧастнаяВТ.Поле1 КАК Поле11
|ИЗ
|ОбщаяВТ КАК ОбщаяВТ
|ПОЛНОЕ СОЕДИНЕНИЕ ЧастнаяВТ КАК ЧастнаяВТ ПО ИСТИНА
|;
|УНИЧТОЖИТЬ ЧастнаяВТ";
Запрос.Выполнить();
//Внутри цикла можно использовать Общую для всех временную таблицу, а любые другие временные таблицы нужно удалять.
КонецЦикла;

Сравнение полного соединения и декартова произведения

ВЫБРАТЬ 1 КАК один ПОМЕСТИТЬ Таб1;
ВЫБРАТЬ 2 КАК два ПОМЕСТИТЬ Таб2;
ВЫБРАТЬ Таб1.один, Таб2.два ИЗ Таб2 КАК Таб2 ПОЛНОЕ СОЕДИНЕНИЕ Таб1 КАК Таб1 ПО ИСТИНА

//Возвращает выборку 1,2;

ВЫБРАТЬ 1 КАК один ПОМЕСТИТЬ Таб1;
ВЫБРАТЬ 2 КАК два ПОМЕСТИТЬ Таб2;
ВЫБРАТЬ Таб1.один, Таб2.два ИЗ Таб2 КАК Таб2, Таб1 КАК Таб1

//Возвращает выборку 1,2;

ВЫБРАТЬ 1 КАК один ПОМЕСТИТЬ Таб1 ГДЕ ЛОЖЬ;
ВЫБРАТЬ 2 КАК два ПОМЕСТИТЬ Таб2;
ВЫБРАТЬ Таб1.один, Таб2.два ИЗ Таб2 КАК Таб2 ПОЛНОЕ СОЕДИНЕНИЕ Таб1 КАК Таб1 ПО ИСТИНА

//Возвращает выборку null,2;

ВЫБРАТЬ 1 КАК один ПОМЕСТИТЬ Таб1 ГДЕ ЛОЖЬ;
ВЫБРАТЬ 2 КАК два ПОМЕСТИТЬ Таб2;
ВЫБРАТЬ Таб1.один, Таб2.два ИЗ Таб2 КАК Таб2, Таб1 КАК Таб1

//Возвращает пусто.

Формирование текста запроса в цикле

Текст0 =
"ВЫБРАТЬ
| АвансовыйОтчет.Ссылка КАК ДокСсылка
|ИЗ
| Документ.АвансовыйОтчет КАК АвансовыйОтчет
|ГДЕ
| АвансовыйОтчет.Дата >= &Дата";
Текст1 = "";
Для Каждого Док ИЗ Метаданные.Документы Цикл
Если Текст1 = "" Тогда
Текст1 = СтрЗаменить(Текст0,"АвансовыйОтчет",Док.Имя);
Иначе
Текст1 = Текст1 + Символы.ПС + "ОБЪЕДИНИТЬ ВСЕ" + Символы.ПС + СтрЗаменить(Текст0,"АвансовыйОтчет",Док.Имя);
КонецЕсли;
КонецЦикла;
Запрос = Новый Запрос;
Запрос.Текст = Текст1;
Запрос.УстановитьПараметр("Дата", НачалоГода(ТекущаяДата()) );
Результат = Запрос.Выполнить();

Все родители элемента справочника одним запросом.

Элегантное решение вместо неуклюжего Родитель.Родитель. Спасибо А.Волокитину за идею.

ВЫБРАТЬ
Данные.Ссылка КАК Ссылка
ИЗ
Справочник.Контрагенты КАК Данные
ГДЕ
Данные.Ссылка = &ЭлементСправочника
ИТОГИ ПО
Ссылка ТОЛЬКО ИЕРАРХИЯ

Остатки на каждый день по РегистрНакопления.ОстаткиПоЯчейкам

Внешний вид громоздкий, но считает максимально быстро. Делать запрос к временной таблице на каждый день в цикле нецелесообразно, поскольку внутри СУБД будут неявно исполняться запросы похожей конструкции.

  1. Получаем перекрестную таблицу: каждая ячейка на каждый день. Дни получаем из регистра, но можно использовать любую другую таблицу.
  2. К входящим остаткам добавляем приход и расход на каждый день. Виртуальные таблицы группированы по измерениям.
  3. Соединение один ко многим. Остаток на каждый день получаем, как добавку к начальному остатку приращений на каждый день, прошедший с начальной даты по нужную.
ВЫБРАТЬ
Ячейки.Ссылка КАК Ссылка,
ОстаткиПоЯчейкамОбороты.Период КАК Период
ПОМЕСТИТЬ ВТ_Ячейки
ИЗ Справочник.Ячейки КАК Ячейки
ПОЛНОЕ СОЕДИНЕНИЕ
(ВЫБРАТЬ РегистрОстатков.Период КАК Период ИЗ
РегистрНакопления.ОстаткиПоЯчейкам.Обороты(&НачалоПериода,
&КонецПериода, День, ) КАК РегистрОстатков) КАК ОстаткиПоЯчейкамОбороты
ПО (ИСТИНА)
ИНДЕКСИРОВАТЬ ПО Ссылка,Период
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ОстаткиПоЯчейкамОстатки.Ячейка КАК Ячейка,
ОстаткиПоЯчейкамОстатки.КоличествоОстаток КАК КоличествоОстаток,
ОстаткиПоЯчейкамОстатки.Номенклатура КАК Номенклатура,
ДАТАВРЕМЯ(1, 1, 1) КАК Период
ПОМЕСТИТЬ ВТ_ОстаткиПоЯчейкам
ИЗ РегистрНакопления.ОстаткиПоЯчейкам.Остатки(&НачалоПериода, ) КАК ОстаткиПоЯчейкамОстатки
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ОстаткиПоЯчейкамОбороты.Ячейка,
ОстаткиПоЯчейкамОбороты.КоличествоПриход - ОстаткиПоЯчейкамОбороты.КоличествоРасход,
ОстаткиПоЯчейкамОбороты.Номенклатура,
ОстаткиПоЯчейкамОбороты.Период
ИЗ РегистрНакопления.ОстаткиПоЯчейкам.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК ОстаткиПоЯчейкамОбороты
ИНДЕКСИРОВАТЬ ПО Ячейка,Период
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТ_Ячейки.Ссылка КАК Ячейка,
ВТ_Ячейки.Период КАК Период,
СУММА(ЕСТЬNULL(ОстаткиПоЯчейкамОстатки.КоличествоОстаток, 0)) КАК КоличествоОстаток,
ОстаткиПоЯчейкамОстатки.Номенклатура КАК Номенклатура
ИЗ ВТ_Ячейки КАК ВТ_Ячейки
ЛЕВОЕ СОЕДИНЕНИЕ ВТ_ОстаткиПоЯчейкам КАК ОстаткиПоЯчейкамОстатки
ПО ВТ_Ячейки.Ссылка = ОстаткиПоЯчейкамОстатки.Ячейка
И ВТ_Ячейки.Период > ОстаткиПоЯчейкамОстатки.Период
СГРУППИРОВАТЬ ПО ВТ_Ячейки.Ссылка, ВТ_Ячейки.Период, ОстаткиПоЯчейкамОстатки.Номенклатура

 

Related Posts

63 Comments

  1. PowerBoy 
    ВЫБРАТЬ
ВЫБОР
КОГДА NULL ЕСТЬ NULL
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ КАК Поле1

    Мне кажется так правильней и предсказуемей

    Reply ↓
  2. vasilev2015

    (1) да, я именно хотел показать, что равенство для NULL не работает.

    Reply ↓
  3. artem_from_minsk

    В таком случае я иногда извращаюсь и пишу на чистом sql, благо 1С прекрасно понимает. До сих пор привычка писать запросы вручную без помощи конструктора запросов. За то есть понимание почему выбирается именно так, а не иначе.

    SELECT

    CASE

    WHEN NULL IS NULL

    THEN ИСТИНА

    ELSE ЛОЖЬ

    END AS Поле1

    Reply ↓
  4. nofear

    «Вывести нумерованный список справочника с помощью запроса»

    Жутко непроизводительное решение. Применимо только в том случае, если элементов — немного.

    Reply ↓
  5. bulpi

    БОЯН ! 🙂

    Reply ↓
  6. vasilev2015

    (4) Можете посоветовать быстрое решение для такой задачи ?

    Reply ↓
  7. nofear

    (6) Другого решения (запросом) нет. Мое замечание касалось лишь того, что бездумно пользоваться предложенным вариантом нельзя.

    Reply ↓
  8. herfis

    Ну, может, новичкам и будет интересно…

    Что касается других задачек, решаемых запросами, просмотрите статьи Ильдаровича, начиная с «Минимализмов».

    Reply ↓
  9. vasilev2015

    (7) согласен

    Reply ↓
  10. vasilev2015

    (8) Ильдарович — Герой.

    Reply ↓
  11. japopov
    При объединении двух таблиц в числовое поле лучше ставить 0, если поле планируем суммировать и Null, если будет функция Максимум (Минимум)

    Вероятно, для любого настоящего спеца 1С это не вопрос уже, но лично я постоянно сталкиваюсь с таким баяном, даже в «типа навороченных» решениях. Допишите в свою коллекцию и выделите жирным:

    Если при суммировании попадаются поля со значением Null, то в результате суммирования получится Null!

    Отсюда хорошая привычка: если планируется результат полученного запроса дальше суммировать, то следует использовать конструкцию ЕСТЬNULL(ТаблицаИзКоторойВыбираем.МоеСуммируемоеПоле,0)

    Разумеется, не забывая подставлять вторым параметром осмысленное выражение подходящего типа (дату — к дате, ссылку — к ссылке, число — к числу…).

    А вообще, спасибо, хорошая подборка, если с умом к ней подходить!

    Reply ↓
  12. herfis

    (11)

    Если при суммировании попадаются поля со значением Null, то в результате суммирования получится Null!

    Вы ошибаетесь. Результатом любого выражения с участием NULL будет NULL. Но в агрегатных функциях (в т.ч. в СУММА) строки с NULL просто игнорируются.

    Иногда это можно использовать (при подсчете ссылок, например).

    Просто если все детальные записи были с NULL, то и СУММА вернет NULL, поэтому и нужна проверка на NULL. Некоторые проверяют на NULL уже результат суммирования и это тоже вполне рабочее решение.

    Reply ↓
  13. vasilev2015

    (11) (12) на платформе 8.2.19 запрос

    ВЫБРАТЬ

    2 КАК Поле1

    ПОМЕСТИТЬ Таб1

    ОБЪЕДИНИТЬ ВСЕ

    ВЫБРАТЬ

    NULL

    ;

    ////////////////////////////////////////////////////////////­////////////////////

    ВЫБРАТЬ

    СУММА(Таб1.Поле1) КАК Поле1

    ИЗ

    Таб1 КАК Таб1

    возвращает 2.

    Reply ↓
  14. JohnyDeath

    (13) Круто! )

    Reply ↓
  15. kuzyara

    Зачем в нумерованном списке запросом при обращении к справочнику использовано ключевое слово РАЗЛИЧНЫЕ? И вы в курсе, что получившийся список будет пронумерован не по наименованию, а в случайном порядке?

    Reply ↓
  16. vasilev2015

    (15) Слово «РАЗЛИЧНЫЕ» не нужно. Про порядок я в курсе ))). Для нумерации по наименованию нужно сравнивать больше-меньше наименование. Однако, если после такой нумерации добавится еще один элемент с каким-то своим наименованием — порядок будет нарушен.

    Reply ↓
  17. saudin

    «Вывести нумерованный список справочника с помощью запроса, если есть только наименование, нет кода» — есть ошибка. Теряется один элемент.

    Reply ↓
  18. saudin

    Надо «ПО (Таб1.Ссылка <= Таб11.Ссылка)»

    Reply ↓
  19. vasilev2015

    (18) Согласен, исправлю. Спасибо за внимательность. Хоть кто-то до конца дочитал )))

    Reply ↓
  20. the1

    (13)

    Имелось в виду что

    ВЫБРАТЬ

    0 + NULL КАК Поле1

    Даст NULL

    Reply ↓
  21. vasilev2015

    (20) Действительно. Добавлю в статью. Кому-то пригодится. Спасибо.

    Reply ↓
  22. serg_infostart

    Не интересно, т.к. это все запросы, до которых можно дойти за приемлемое время в процессе работы.

    Интересны были бы какие-то фичи, ускоряющие, уменьшающие код, улучшающие понимание, типа «Распределение в запросе» или «избавляемся от перебора»

    Reply ↓
  23. vasilev2015

    (22) Коллекция нужна. Дональд Кнут и Ильдарович тоже коллекции собирали )))

    Reply ↓
  24. DrAku1a

    «Аналог среза последних» — позволяет например, получить срез последних по определенному типу регистраторов, бывает нужно. Работает быстро.

    «Неожиданный результат запроса» — ничего неожиданного, если помнить правило: Любое* математическое или агрегатное выражение с NULL — вернёт NULL, а любое* логическое выражение с NULL — всегда вернёт Ложь. Этим «NULL» отличается от «Неопределено».

    * — Кроме двух специфичных функций ЕстьNULL() и Есть NULL, которые как раз используются для работы с NULL-значениями.

    Reply ↓
  25. saudin

    Статья полезная. Я для себя пару запросов сохранил, чтоб не доходить «за приемлемое время в процессе работы», а просто взять и применить.

    Reply ↓
  26. vasilev2015

    (24) Здравствуйте, Андрей !

    Пользуюсь Вашей консолью для уничтожения вложенных запросов, спасибо.

    (24)

    Любое* математическое или агрегатное выражение с NULL — вернёт NULL

    По поводу агрегатного выражения я тоже так думал, но посмотрите ответ (13).

    Reply ↓
  27. stol6

    «Найти документ, для которого сумма всех последующих документов меньше заданной, а сумма всех последующих документов вместе с его суммой – больше заданной.».

    Что за белиберда? Из-за этого дальше и читать не хочется….

    Reply ↓
  28. vasilev2015

    (27) Это дословный перевод на русский язык конструкции

    ИМЕЮЩИЕ СУММА(Таб11.СуммаДокумента) < &СуммаПоследнихНеоплаченныхНакладных

    И МАКСИМУМ(Таб1.СуммаДокумента) + СУММА(Таб11.СуммаДокумента) >= &СуммаПоследнихНеоплаченныхНакладных

    Как сформулировать лучше ?

    Reply ↓
  29. DrAku1a

    (26) Согласен. Насчёт агрегатных функций — 1С поступает умнее. Выходит, NULL получается только когда ВСЕ суммируемые параметры равны NULL. Интересно.

    Reply ↓
  30. ADirks

    (26) А зачем уничтожать вложенные запросы? В чём профит?

    Reply ↓
  31. vasilev2015

    (30) вложенные запросы не рекомендуют по новым стандартам. У меня база старая, там их много. Иногда с вложением три, четыре раза. Читать мне непривычно.

    Reply ↓
  32. ADirks

    (31) Аргумент «не рекомендуют» меня честно говоря каждый раз веселит 🙂 Ну что за религия то. Как они хоть это объясняют то?

    Кстати, всякие виртуальные таблицы, типа срезов последних, на сервер уходят как раз со вложенными запросами, и ничего.

    Грамотно оформленные подзапросы могут существенно улучшить читабельность, и вообще упростить жизнь.

    например, сравним

    SEL ECT

    …,

    Данные.Поле1

    FR OM

    (

    SEL ECT

    … ,

    CASE

    WHEN … THEN 10

    WHEN … THEN 20

    WHEN … THEN 30

    END Поле1

    FR OM

    …

    ) Данные

    WHERE

    Данные.Поле1 >= 20

    ORDER BY

    Данные.Поле1

    и

    SELECT

    … ,

    CASE

    WHEN … THEN 10

    WHEN … THEN 20

    WHEN … THEN 30

    END Поле1

    FR OM

    …

    WH ERE

    CASE

    WHEN … THEN 10

    WHEN … THEN 20

    WHEN … THEN 30

    END >= 20

    ORDER BY

    CASE

    WHEN … THEN 10

    WHEN … THEN 20

    WHEN … THEN 30

    END

    Иной раз эти кейсы такие развесистые бывают, шоажкапец. А потом в этот кейс надо добавить ещё ветку, и редко когда это происходит с первого раза правильно (т.е. синхронно во всех местах).

    Что же касается времени выполнения запроса, и его ресурсоемкости — то наличие/отсутствие подзапросов в подавляющем большинстве случаев никак не сказывается. Всё равно SQL сервер всё сделает как ему удобнее.

    Reply ↓
  33. vasilev2015

    (32) обычно для таких случаев я использовал временные таблицы. Но возможно, есть рациональное зерно и во вложенных запросах.

    Reply ↓
  34. ADirks

    (33) Временные таблицы в такой ситуации — это просто лишняя нагрузка на tempdb. Вот просто лишняя, на совершенно ровном месте.

    Reply ↓
  35. herfis

    (32) Да просто злоупотреблять вложенными запросами не стоит. Хотя многие новички эту рекомендацию воспринимают как «никогда не используйте вложенные запросы!». Нужна золотая середина. Слишком сложные моно-запросы сложнее анализировать и выше вероятность, что оптимизатор запросов может лажануть (и лечить это будет сложнее). Особенно, если кроссплатформенность интересует. В том же postgresql оптимизатор запросов менее продвинутый, чем в mssql. Во всяком случае, у меня сложилось такое впечатление. Ну, в параметрах виртуальных таблиц точно не стоит вложенные запросы использовать 🙂

    Но если вообще избегать вложенных запросов — так это другая крайность. Сплошь и рядом это совершенно ненужная декомпозиция и по производительности тоже не айс, так как у оптимизатора не остается шансов на выбор более эффективного плана выполнения.

    Reply ↓
  36. vasilev2015

    (34) (35) И я за золотую середину ! :))

    Reply ↓
  37. slawanix

    может и мне пора ради лайков вывесить свои абстрактные для остальных и реальные в каждом конкретном случае для себя запросы показать, вдруг кто-нибудь лайкнет.

    Reply ↓
  38. endym

    как по мне некоторые решения повергают меня в ступор…

    1) запрос в цикле

    2) передача в предусловие конструкции «Выбрать… »

    3) столько статей по декартову произведению, а тут нумерацию «накопительным итогом» предлагают 😉

    может для самописных мелких баз это еще сгодится, но для масштабируемых решений это погибель

    Reply ↓
  39. herfis

    (38)

    3) столько статей по декартову произведению, а тут нумерацию «накопительным итогом» предлагают 😉

    Там по сути и есть декартово произведение. То, что условие отбора в соединении, а не в ГДЕ — непринципиально. Так просто более компактно.

    Но судя по вашему снисходительному замечанию, вы можете предложить более оптимальный вариант нумерации строк в запросе. Очень хотелось бы на него посмотреть.

    Reply ↓
  40. vasilev2015

    (37) Вывешивайте, я лайкну. Или напишите — какие задачи эти запросы решают, я постараюсь их угадать и добавить к этой статье.

    Reply ↓
  41. vasilev2015

    Напишите ваше сообщение

    (38)

    1. Запрос в цикле — мне тоже неприятно. Однако процедура перепроведения документов за порождает именно запросы, именно в цикле. А здесь — красивая идея передавать временную таблицу внутрь цикла.

    2. Поясните, что значит предусловие ?

    3. Нумерация накопительным итогом — встречается на собеседованиях. Я предупредил.

    Reply ↓
  42. vasilev2015

    (37) Коллега, я поставил лайки на Ваши существующие статьи. Киньте мне идею: какие запросы добавить ?

    Reply ↓
  43. vasilev2015

    (39) Спасибо за хорошие слова.

    Reply ↓
  44. endym

    (41)

    1. Запрос в цикле — я бы заменил на генерацию 1 запроса из запроса-шаблона, и поиском в результате.

    2. предусловие — это условие в виртуальной таблице (остатки, обороты, срез первых/последних)

    3. Как для теории — решение хорошее, для высоко нагруженных систем, но как накопительный итог, а не нумерацию. нумерацию можно получить из СКД и выгрузкой/выводом на Ваше усмотрение

    Reply ↓
  45. endym

    (39)

    более оптимальный вариант нумерации строк в запросе

    для нумерации — СКД (служебное поле «номер по порядку»)

    я никоим образом не писал в снисходительном тоне.

    Reply ↓
  46. vasilev2015

    (44) 1. Бывают ситуации, когда запрос исполняется в цикле. Как правило, между выполнением таких запросов меняются данные и сделать, как Вы пишете, невозможно. Пример я приводил.

    2. Про виртуальную таблицу смотрите подробнее https://its.1c.ru/db/metod8dev/content/5457. После этой статьи я понял, что лучше в условиях виртуальной таблицы делать простой запрос.

    3. Нумерация мне встретилась на собеседовании, причем просили реализовать именно в запросе, без СКД. В реальной жизни не встречал.

    Reply ↓
  47. slawanix

    (42), Николай, право, не стоило. Я же не напрашиваюсь на лайки. Просто не вижу для себя практической пользы от статьи, разве что интересным показался пример с нумерацией, чисто в учебных, опять же, целях. Согласен, кому-то статья будет полезной.

    Reply ↓
  48. vasilev2015

    (47) Можете придумать, что еще в статью добавить ?

    Reply ↓
  49. matveev.andrey.v

    (34) абсолютно согласен с Вами, никогда не понимал этой регилии временных таблиц, да они нужны когда используешь их в связях и когда сами таблицв очень большие, но везде их вставлять…

    Reply ↓
  50. dnkon

    Такой запрос с нумерацией быстрее в среднем в 2 раза на 1000 элементов.

    ВЫБРАТЬ РАЗЛИЧНЫЕ
Справочник.Ссылка КАК Ссылка,
1 КАК Нумератор
ПОМЕСТИТЬ Таб1
ИЗ
Справочник.Справочник КАК Справочник
;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
Таб1.Ссылка,
СУММА(Таб1.Нумератор) КАК Нумератор
ИЗ
Таб1 КАК Таб1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таб1 КАК Таб11
ПО Таб1.Ссылка <= Таб11.Ссылка

СГРУППИРОВАТЬ ПО
Таб1.Ссылка

УПОРЯДОЧИТЬ ПО
Нумератор

    Показать

    Reply ↓
  51. vasilev2015

    (50) Согласен, здесь операции проще. Включу в следующую редакцию, вставлю на Вас ссылку.

    Reply ↓
  52. mitia.mackarevich

    Сравнивать ссылки это эпично

    Reply ↓
  53. Aleskey_K

    Если применяете сортировку в запросе, то индексировать не нужно. Обратное утверждение так же имеет силу.

    Reply ↓
  54. VmvLer

    — слишком много условностей а ля «для которых нет совпадения»…, «может/не может»

    — слишком много банальных идей

    — слишком много не оптимальных по производительности решений без учета громадных таблиц

    Reply ↓
  55. vasilev2015

    (53) Приведите пожалуйста источник. На уровне SQL эти действия выполняются одинаковыми операторами, но вряд ли оператор сортировки сделает операцию Index Insert.

    Reply ↓
  56. vasilev2015

    (54) Здравствуйте !

    я математик, привык везде определять область допустимых значений, граничные условия. Как иначе ?

    Почитайте Дональда Кнута. Двадцать разновидностей сортировки. Смешные названия: гномья сортировка, глупая сортировка. Банально, да ?

    Оптимизация в этой теме не рассматривается, так задумано.

    Все о чем написал, сам использовал. Например за год расчет остатков на каждый день использовал два раза в отчетах, один раз на собеседовании.

    Напишите свою статью. Обязательно плюс поставлю.

    Reply ↓
  57. vasilev2015

    (55)(53) Согласен, не нужно.

    Reply ↓
  58. vasilev2015

    (50) Кстати, тут слово «Различные» не нужно. При выборке из справочника ссылки будут все разные. Так еще быстрее.

    Reply ↓
  59. CratosX

    (19) таки в (17) заметили, что последний элемент не пронумерован

    Reply ↓
  60. CratosX

    (35) вложенная таблица эффективна, если в ней минимальное количество строк (в идеале одна).

    Мнемонически можно запомнить «вложенная таблица фильтрует, а не добавляет»

    Reply ↓
  61. herfis

    (60) Увы, но нет. Это слишком большое упрощение. Есть как случаи, когда есть смысл писать во временную таблицу маленькую выборку, так и случаи не писать большую. И наоборот.

    Reply ↓
  62. CratosX

    «Вывести нумерованный список справочника с помощью запроса, если есть только наименование, нет кода»

    в платформе с версии 8.3.13.1513 Упрощено создание монотонно возрастающего уникального ключевого поля для временной таблицы.

    ссыль

    Реализована возможность создания поля с уникальными (в рамках одной таблицы), последовательно возрастающими значениями.

    Реализована функция языка запросов АВТОНОМЕРЗАПИСИ(), которая может быть использована только при создании временной таблицы.

    Не поддерживается использование функции АВТОНОМЕРЗАПИСИ():

    в запросах, содержащих ОБЪЕДИНИТЬ на верхнем уровне;

    в запросах, не формирующих временную таблицу;

    вне списка выборки;

    в выражениях.

    Reply ↓
  63. vasilev2015

    (62) Круто ! Реально полезная цитата.

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *