Имя: Пароль:
1C
1С v8
Результат сравнения в запросе
0 Zero on a dice
 
04.12.13
12:43
Был ли у кого прецедент сравнения полей в запросе с ориентированием на скорость обработки?
буквально, нужно выбирать результат сравнения "реквизит1=реквизит2 как поле1" с типом булево.
кроме как выбор-когда, есть что-то интереснее?
тип реквизитов всегда идентичен.

выбор-когда, насколько я понимаю, замедлит выполнение, а прямая конструкция в запросе не работает. постобработку тоже, прошу не предлагать.
1 kosts
 
04.12.13
12:45
(0) Почему выбор замедлит?
2 Рэйв
 
04.12.13
12:45
Чего это он замедлит? Тоже что и обычное "если" только языком запроса
3 Zero on a dice
 
04.12.13
12:47
дык, выбор когда - операция раз, сравнение - операция два
или не так?
4 Рэйв
 
04.12.13
12:48
(3)Ну ты еще такты процессора посчитай.
5 Wobland
 
04.12.13
12:48
(3) тогда храни результат сравнения в базе. и регламентно обновляй
6 Zero on a dice
 
04.12.13
12:48
я сужу по аналогии с обычным если, какой смысл использовать конструкцию:
Если а=б тогда Истина; иначе Ложь; КонецЕсли;
7 Wobland
 
04.12.13
12:49
(6) смысл в том, что другой у тебя нет
8 Zero on a dice
 
04.12.13
12:51
(7) так вопрос и был, есть ли альтернатива?
вне запроса я буду использовать конструкцию "результат = (а=б)", в запросе конкретно эту конструкцию использовать - не получается
9 zladenuw
 
04.12.13
12:53
(8) ну так условие пишет
выбор когда а=б тогда истина иначе ложь конец
10 Zero on a dice
 
04.12.13
12:56
(9) еще раз, меня интересует альтернатива конструкции "выбор-когда", которая может работать быстрее.
я такой альтернативы не знаю, потому и ветку открыл, ибо факт моего незнания не означает отсутствие альтернативы.
11 zladenuw
 
04.12.13
12:58
да куда быстрее. ты с языком sql знаком ? есть там другая альтернатива ?
12 kosts
 
04.12.13
12:59
Проиндексируй реквизиты. Проиндексируй поля временных таблиц, если есть.
13 МихаилМ
 
04.12.13
13:01
(11)
есть.
реляция с таблицей
14 Sammo
 
04.12.13
13:03
1. Альтернатива в СКД вычисляемое поле. Но я сильно смоневаюсь, что оно будет быстрее, поэтому при данной постановке задачи не подойдет.
2. Выбор в данном случае на скорость повлияет не сущестенно.
15 МихаилМ
 
04.12.13
13:04
тк 1с8 может использовать несколько субд,
для обсуждения такой странной отимизации
уместно указать платформу 1с и тип исполнителя запроса (субд)
включая ос.
16 Zero on a dice
 
04.12.13
13:10
(15) скуль, 8.2.18, 64х
с самим скулем знаком слабо, таить нечего, посему размышляю в рамках обычного кода с поправками на правила и опыт оптимизации.
в данный момент запрос реализован через "выбор-когда", но, мне кажется, это не самое оптимальное решение.
17 Рэйв
 
04.12.13
13:11
(16)Другого нет.
18 Как страшно жить
 
04.12.13
13:12
(3)
>>выбор когда - операция раз

простите, что за операция?
19 Zero on a dice
 
04.12.13
13:14
(18) это придирки? могу назвать итерацией, это сильно меняет контекст, или в приведенном примере, действительно, неверная логика?
20 Как страшно жить
 
04.12.13
13:16
(19) основные затраты сервера (если там конечно не рекурентная хранимая процедура) это чтение, запись и "борьба транзакций"

ускорять запрос в данном случае неуместно
21 Zero on a dice
 
04.12.13
13:21
интерес в данном случае заключается в том, что обрабатывается временная таблица. то есть, фактически, насколько я понимаю работу сервера sql, выполняемые операции в большинстве своем равнозатратны.
хотя, если я не прав, прошу поправить
22 kosts
 
04.12.13
13:26
Выложи запрос
23 Zero on a dice
 
04.12.13
14:58
Запрос динамический, в кратце: две таблицы значений грузятся во временные, соединяются полным соединением по прямому сравнению одного поля и сверяется равность реквизитов.
структура таблиц идентичная за исключением одной колонки, являющейся ссылкой (только у одной из таблиц), остальные поля - примитивных типов (строки есть, но, естественно, ограниченной длины) колонок в таблице от пары-тройки до нескольких десятков.
сверяются и выбираются все поля, кроме ссылки.

запрос в общем виде следующий
ВЫБРАТЬ
|    ВТ_Местная.Ссылка,
|    ВТ_Местная.ИД" + ВставкаВЗапрос1 +"
|ПОМЕСТИТЬ ВТ_Местная
|ИЗ
|    &ВТ_Местная КАК ВТ_Местная
|;ВЫБРАТЬ
|    ВТ_Удаленная.ИД" + ВставкаВЗапрос2 +"
|ПОМЕСТИТЬ ВТ_Удаленная
|ИЗ
|    &ВТ_Удаленная КАК ВТ_Удаленная
|;
|Выбрать
|ВТ_Местная.Ссылка"+ВставкаВЗапрос3+"
|ИЗ
| ВТ_Местная как ВТ_Местная Полное соединение ВТ_Удаленная как ВТ_Удаленная ПО ВТ_Местная.ИД= ВТ_Удаленная.ИД

где третья вставка, сейчас, следующего вида:
(Выбор когда ВТ_Местная.р1= ВТ_Удаленная.р1 тогда истина иначе ложь конец) КАК поле1
24 kosts
 
04.12.13
15:12
(23) В данном случае долгой операцией будет загрузка параметров (т.е. ТЗ) в твой запрос, а не само выполнение запроса.
И нужно проиндексировать реквизиты ВТ_Местная.ИД и  ВТ_Удаленная.ИД.

Попробуй переделать свой алгоритм так, что бы всё можно было получить запросом без подгрузки ТЗ через параметры. Т.е. всё сделать одним запросом.
25 Zero on a dice
 
04.12.13
15:28
(24) другому алгоритму не быть - одна из таблиц приходит извне, другая не может быть обработана в запросе.
запросом таблицы обрабатываются, потому что сервер sql сделает это быстрее, чем любой другой алгоритм на "восьмерке".
таблицы большие, поэтому вариант "оптимизировать на мелочах" очень даже приемлем.
26 kosts
 
04.12.13
15:36
(25) > другая не может быть обработана в запросе
Возможно и может. В запросах можно такое накрутить если подумать...
По любому если таблица не приходит извне, значит приходит с сервера. Обработав её без пересылки туда сюда, можно существенно ускорить.

>запросом таблицы обрабатываются, потому что сервер sql сделает это быстрее, чем любой другой алгоритм на "восьмерке".
Если учесть, что выполняется пересылка данных, то вполне может оказаться, что обработать в клиенте будет быстрее...
Если к этому грамотно подойти через индексируемые типы.