Помогите разобраться с решением билета 6.1.

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

Смущает: "для изменения" - задано своеобразно.

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

Оптимально ли тут применяется "" для изменения"?

Задача 6.1:

Документ РеализацияТоваров осуществляет движения по регистру ОстаткиНаСкладах, а именно списывает реализованное количество товаров со склада. В обработчике проведения документа выполняется проверка превышения лимитов - минимального допустимого остатка товара на складе и максимально допустимого размера отгрузки со склада. Запрос выглядит следующим образом:

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

Укажите неоптимальные решения в данном запросе и предложите варианты исправления.

* - параметры ВИРТУАЛЬНЫХ таблиц необхоодимо указать, но тут возможны варианты

там управляемые блокировки?

(2) Про режим нет уточнения, поэтому отвечать необходимо для "Авто" думаю

а варианты ответов какие?

1) Соединения с подзапросом здесь нет
2) Соединение с виртуальной таблицей - не факт, нужно знать структуру измерений этих регистров, чтобы поля соединения в индексы попадали

можно уменьшить размер выборки если задать условия сразу в запросе

тут лимиты вообще не используются

(3) по умолчанию в 1С управляемые блокировки, если не ошибаюсь

(8) Это же экзамен. Там по всем версиям спрашивают

(5) Прямого соединенипя нет, но есть соединение выборки из подзапроса. Если СКУЛЬ ошибся в подзапросе, то на более высоком уровне это сыграет свою роль. Не так?

еще момент.
можно в фильтр по остаткам добавить номенклатуру

(7) Да, это и смущает.

В запросе нет, в условии есть. Как ответить?

(11) Да, это упомяналось:
параметры ВИРТУАЛЬНЫХ таблиц необхоодимо указать, но тут возможны варианты

Про параметры остатков тоже все двояко:

- условие "номенклатура в (выбрать...из ВТ)" само по себе не очень быстрое.

- оставлять без фильтра - значит получить все остатки, тоже не быстро.

Понятно что у SQL свое мнение и сделает он по своему в не зависимости от вашего выбора. А экзаменатору то как ответить?

> условие "номенклатура в (выбрать...из ВТ)" само по себе не очень быстрое.
Откуда инфа?

(10) Не так. Если идет просто выборка из подзапроса, то ничего плохого в этом нет, будь их хоть 10 этажей.
Сам запрос то что выбирает в итоге? Кол-во из документа и остаток. Лимиты в выборку не попадают. Как их контролировать?

(14) - условие "номенклатура в (выбрать...из ВТ)" само по себе не очень быстрое.
имхо побыстрее чем выбрать из подзапроса.

И еще ответьте сами себе на вопрос что будет заблокировано при выполнении запроса и насколько?

в запросе (0) ошибка "Товары.КоличествоНаСписание"? Нет в подзапросе такого поля.

(16) В данном запросе явно указано выбрать "Товары.Номенклатура И Остатки.КоличествоОстаток"

Товары - подзапрос!
Остатки - вирт. таблица(будем считать что иногда подзапрос)

т.е. подзапрос есть всегда. ЧЯДНТ?

(20) да ерунда это все. Ответ на (0) в (18)

Если речь идет об экзамене, то отвечать надо строго по этому списку и ничего не выдумывать:
https://kb.1c.ru/articleView.jsp?id=44

Что касается ДЛЯ ИЗМЕНЕНИЯ, то я бы ответил просто то, что я знаю про эту команду. Скорее всего, для преподавателя это просто зацепка, чтобы переключится на более сложную тему.

(22) Я знаю про эту команду - это не ответ

(23) Имею в виду, все мысли по поводу использования этой команды в запросе

У Хрусталевой рекомендуется товары выбрать во временную таблицу, остатки выбрать во временную таблицу, а потом соединять. Глава 4. Оптимизация запросов.

(21) Мой ответ: ТоварыНаСкладах - ю блокировкой,
с отбором по складу*, по номенклатуре* - смотря где задать условие. Но возможны варианты - не сказано ничего про наличие индексов, и не задана структура регистра. Тут расказать что-да как про кластерный индекс регистра.

Проблокировки регистров сведений тут трудно ответить, ведь в результате запроса их нет, а субд скорее всего и не будет их обрабатываь.

Spieluhr, так совсем не верно?

(25) + во временных таблицах индексировать поля дальнейшего соединения.

Тут всего 2 действия:
1) Вынести подзапрос в ВТ
2) Условие по складу из параметров ВТ перенести в условия соединения.

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

(26) Про блокировки регистров сведений надо ответить, если есть желание, чтобы экзамен продолжился дольше 30 сек

Мне кажется, что здесь неудачное соединение.
Судя по тому, что
ПО Остатки.Номенклатура = Товары.Номенклатура
внизу и по условиям соединений с лимитами, происходит соединение остатков с лимитами по номенклатуре и по складу. Зачем?
Имхо, соединять надо остатки с лимитами, тогда размер выборки будет меньше.
+ да, простой вложенный запрос не аукается, но уже более сложные варианты могут негативно аукаться на плане, поэтому мне лично было бы удобнее вынести табличную часть в отдельную временную таблицу и потом использовать ее.
+ для изменения в проведении. Насколько я помню сейчас общая рекомендация - списываем и потом смотрим, что получилось.

(29) Не знаю, как где. Читаю сейчас Хрусталеву.
Есть прям пример оптимизации:

Делаем выборку из табличной части документа во временную таблицу, далее получаем остатки, указывая в фильтре "Номенклатура В (ВЫБРАТЬ ... ИЗ ВременнойТаблицыТоваровТабЧасти)". В обеих индексируем Номенклатуру, т.к. по ней соединяем.

(31) Что там надо ответить? Что никаких проблем с ней нет?

+32 на из забавного - ну приджоинили мы РС Лимиты, а дальше что? как они используются? Если вывода нет, суммирования нет, проверок в запросе нет

(31) Тебя сами спросят, если захотят. А если это будет Морозов, то и не спросит, ему больше интересен кластер серверов и 100500 его настроек.

(35) да, в этом и вопрос. На каком этапе они отсеятся и дойдет до них блокировка?

Написано: "Вместо вложенных запросов в соединениях ВСЕГДА нужно использовать временные таблицы."

(38) И тут я бы мог поспорить с 1С:-) Но не буду. В 99.9% они правы.

(39) К сожалению, экзамен - это знать то, что дает именно 1С.

+(38) Следующее предложение: "При этом их необходимо проиндексировать по полям, участвующим в условии соединения.".

(41) - индексация этих временных таблиц по полям соединений ,это в (0)

(38) Скажем так, в общем случае лучше так. И 41 тоже.
Но есть моменты, когда это не сыграет.
+ надо учитывать, что временные таблицы - это рост tempDB.
Кстати, я по старой памяти всегда делаю Уничтожить временную таблицу, хотя сейчас вроде последнее время не было с этим косяков.

(43) "Но есть моменты, когда это не сыграет. "
В большинстве моментов это не сыграет.
Вы лучше отсортируйте эту ВТ по полям кластерного индекса той таблицы, с которой будете соединять.

(44) Хотя нет. Лучше с ВТ ничего не делать вообще.

(43)я тоже уничтожаю.

(42) Вот что есть про ДЛЯ ИЗМЕНЕНИЯ:    
- Данная конструкция  игнорируется вне транзакции
- ДЛЯ ИЗМЕНЕНИЯ актуально ТОЛЬКО для автоматического режима управления блокировок (в режиме управляемых блокировок следует использовать объект БлокировкаДанных).

(46) Неправильно.
Самое главное:
ДЛЯ ИЗМЕНЕНИЯ заставляет сервер SQL ставить x блокировку (вместо s) на прочитанные запросом 1С строки таблиц и индексов.

(45) Вы предлагаете все таки не выносить запрос к остаткам в отдельный пакет, соединять как есть?

(48) Да.

(44)
+ надо учитывать, что временные таблицы - это рост tempDB.

в данном случае не те размеры
т.е. учитывать это не нужно

(43)
> Кстати, я по старой памяти всегда делаю Уничтожить временную таблицу, хотя сейчас вроде последнее время не было с этим косяков.
Это тоже лишнее, если не используется менеджер ВР

(47) U блокировку
(49) Тут может быть подзапрос, а мы на экзамене. В жизни то ясно что можно нарушать правила и иногда нужно

*ВТ

(48) На экзамене 1С вас за это могут предать анафеме, но если сможете доказать и объяснить, почему - то может прокатить.

Кстати, то, что в (46), в разделе "1С » Сертификация 1С » 1С Эксперт » ДЛЯ ИЗМЕНЕНИЯ в запросах 1С 8"

(53) Да, простите, U. Ошибся. Главное, что не совместимую с S. Что защищает от деадлока.

(47) Там именно про U и сказано.

(44) сортировать ничего не нужно
индексировать можно

(59) Да, сортировать бессмысленно. Как и индексировать в 90% случаев.

(60) почему 90?

(52) Помнится был релиз (правда еще 8.1, если мне не изменяет мой склероз), где очистка не работала при удалении менеджера. Так что лучше подстраховаться. А то будет очередной сюрприз. Но это сугубое имхо.

(60) Часто имеет смысл прикинуть - даст ли время потраченное на создание индекса соответствующий прирост производительности. В подобных простых ситуациях обычно не даёт. Имхо.

(62) + иногда бывает что индекс создан, а субд решил его не использовать.

(38) (41) (43) Причина таких рекомендаций простая. База это не всегда SQL Server. В каждой базе свои тараканы. А с ВТ везде будет работать гарантировано "неплохо". Хоть и не всегда оптимально.

Насчет блокировок. Если проверять и остатки и лимиты прямо в запросе, блокировки возможно вообще не потребуется.

(61) Да, пожалуй во всех 100%.
ВТ должна быть больше РН, чтобы ее индекс имел смысл. Это десятки тысяч строк. Это дичь пихать эту выборку в ВТ.

Обычно это будет выглядеть, как перебор строк ВТ (nested loops) и поиск по индексу в РН. Индекс ВТ - не используется.

Иногда это будет выглядеть, как параллельный перебор строк ВТ и строк РН. (merge join) ВТ при этом будет предварительно отсортирована по строкам, аналогичным строкам кластерного индекса РН. При этом индекс ВТ будет не использован, либо, если он есть и порядок колонок в нем совпадают с порядком колонок кластерного индекса РН - SQL будет читать из него (не искать). Это, пожалуй, единственный случай его использования, вот почему я сказал, что проще ВТ отсортировать.

(66) Ну и hashjoin - ВТ также будет прочитана предварительно, индекс ВТ использован не будет.

(66) Вариант - в документе реализация 99 тысяч строк.

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

(69) Ну вот это и есть эти 10%. Как часто такое встречается?
Как долго живет такая таблица? Я думаю, она живет 5-6 чтений к ней. Делать ли в данном случае для нее индекс?

(70) 5-6 чтений - это в очень лучшем случае. В большинстве - пару раз чтение - тут индекс однозначно не нужен.

(70) (71) См. (64)

(70) почему 5-6 чтений? а не 10-20?

(72) Я говорю за SQL. В других не разбираюсь.

(73) Ну, значит вам повезло. Я с таким - не встречался (слава Гейтсу).

(75) могу согласиться с 90%
в моей практике подобные примеры были при обменах конвертацией
когда есть большая временная таблицы и поиск в ней выполняется очень большое количество раз