|
Результат сравнения в запросе | ☑ | ||
---|---|---|---|---|
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 сделает это быстрее, чем любой другой алгоритм на "восьмерке". Если учесть, что выполняется пересылка данных, то вполне может оказаться, что обработать в клиенте будет быстрее... Если к этому грамотно подойти через индексируемые типы. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |