Имя: Пароль:
1C
1С v8
Есть ли способ ускорить выполнения запроса?
0 ytex
 
16.11.16
11:50
Добрый день.
В справочнике Партнеров, есть реквизиты: телефон и почтовый адрес.
Необходимо запретить создание и сохранение нового партнера, если уже использовался данный номер телефона или почты.

ВЫБРАТЬ
    ПартнерыКонтактнаяИнформация.Тип,
    ПартнерыКонтактнаяИнформация.Представление
ИЗ
    Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКонтактнаяИнформация
ГДЕ
    ПартнерыКонтактнаяИнформация.Тип = &Тип
    И ПартнерыКонтактнаяИнформация.Представление = &Представление

В справочнике содержаться 3-4 тыс элементов, понятно что запрос по поиску совпадений выполняется долго, подскажите можно ли ускорить запрос? что можно сделать, чтобы поиск выполнялся быстрее?
1 Господин ПЖ
 
16.11.16
11:51
в индекс не попадаешь
2 Лефмихалыч
 
16.11.16
11:53
(1) а его и не может быть, индекса - представление неограниченной длины.

Решение - вынести "использованные" телефоны в отдельный РС, где они будут храниться в индексированном поле ограниченной длины. И искать по нему перед записью, а не по ТЧ. В РЧ записывать при записи партнера
3 Лефмихалыч
 
16.11.16
11:57
а если представление ограниченной длины, то можно просто индексирование включить у полей Тип и Представление.
4 mistеr
 
16.11.16
12:52
(0) Можно попробовать полнотекстовый поиск.
5 HardBall
 
16.11.16
15:33
(0) Почему должно быть понятно, что запрос выполняется долго?
Где Номер телефона и почты в запросе?
3-4 тысячи элементов это много?
Что творится?
6 MrStomak
 
16.11.16
15:40
(0) А давай использовать для поиска не Представление, и НомерТелефона (если мы говорим про подсистему КИ из БСП)?
Индекс по нему включил и всё, проблемы нет.
7 MrStomak
 
16.11.16
15:42
(3) Вот это плохой совет.
Если индексирование включить у "Тип" и "представление", то будет 2 индекса, которые не пересекаются.
Фактически СУБД сможет использовать для поиска только 1 из них.
Нужно самому выбирать наиболее селективный реквезит, т.е. "Представление" (но на самом деле - НомерТелефона =])
8 rphosts
 
16.11.16
15:42
>ПартнерыКонтактнаяИнформация.Представление = &Представление

ужас!
9 rphosts
 
16.11.16
15:42
хотя юзера со своими хотелками такие юзера...
10 rphosts
 
16.11.16
15:44
(3) достаточно по типу... представление в 8.3.5 и далее можно менять программно.
11 MrStomak
 
16.11.16
15:45
(10) Представление - это реквизит табличной части. Строка(500).
12 Лефмихалыч
 
16.11.16
15:46
(7) вообще да. Но, кстати, отбор по типу в запросе тут нах не нужен, раз там равенство.
13 rphosts
 
16.11.16
15:48
(11) да лана, модуль магнагера справочника:
Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка)
бла-бла-бла
КонецПроцедуры

8.3.6.2152 если чё
14 H A D G E H O G s
 
16.11.16
15:49
Интересно, СУБД когда-нибудь допилят до хранения хэша поля, которое указал программер в дизайнере?
15 MrStomak
 
16.11.16
15:50
(13) Ты еще раз перечитай, чтоли - Представление - это реквизит табличной части конкретного справочника. Его так назвали. А могли назвать ПредставлениеКотороеНеФункцияПредставленияСправочникаЧтобыНиктоНеПерепутал. Но не стали.
16 MrStomak
 
16.11.16
15:51
(14) Не понял тебя, раскрой мысль
17 rphosts
 
16.11.16
15:51
(14) это анрил, я-ж могу какой угодно код в зависимости от чего угодно туда запихать...

(11) хотя если конфа под желтым замков - можно и так, но без гарантий, что после очередного обновления не перестанет работать
18 H A D G E H O G s
 
16.11.16
15:52
(14) Ну и его асинхронное обновление. И глобальные флаг у таблицы "ХешПоляПредставлениеАдресаАктуален". И искать уже по нему, а не по мегабайтам сырых данных.
19 MrStomak
 
16.11.16
15:52
(12)
Ну как бы да. Тут только есть чисто техническая возможность указать адрес в номере телефона и получить два разных типа на одном представлении... Так что на всякий случай лучше доотбирать тип...
20 H A D G E H O G s
 
16.11.16
15:53
(18) Это технически на порядок проще, чем полнотекстовый поиск.
21 H A D G E H O G s
 
16.11.16
15:54
(17) По моему ты чет не вкурил. Или я не понял твоих мыслей.
22 Лефмихалыч
 
16.11.16
15:54
(19) если так будут делать, то их ни чего не спасет
23 H A D G E H O G s
 
16.11.16
15:55
При этом хеш - тип данных - фиксированный, хранится в самих страницах данных таблицы, за ним не надо лезть в страницы потоковых данных как с сырыми данными, вот он тут.
24 MrStomak
 
16.11.16
15:56
(23) Какую задачу всё это будет решать? Поиск - а есть ли уже такое? Опиши сценарий использования, непонятно.
25 H A D G E H O G s
 
16.11.16
16:00
(24) Поиск по "сырому" полю. Для искомого значения строим хеш и ищем по колонке "хеш", которую можно (и нужно) проиндексировать. Ну а потом keylookup, что лучше чем scan.
26 H A D G E H O G s
 
16.11.16
16:01
Соединение по сырым полям 2-х таблиц. Вместо сырых полей подставляются поля с из хешем.
27 H A D G E H O G s
 
16.11.16
16:02
Да и сам алгоритм сравнения 2 х хешей занимает меньше ресурсного времени чем сравнение 2-х сырых данных.
28 MrStomak
 
16.11.16
16:02
(25) В чем принципиальное отличие от индекса, кроме невозможности использования условий на больше-меньше?
29 MrStomak
 
16.11.16
16:03
(25) Для keylookup нужно знать позицию строки в таблице. Где она будет? Как будет поддерживаться актуальность этой информации?
30 H A D G E H O G s
 
16.11.16
16:05
Мне лениво пытаться тебе объяснять. Я уже все объяснил и не понимаю, что тебе не понятно.
31 MrStomak
 
16.11.16
16:47
(30)
Ну сложно понять твою мысль.

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

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

Выигрыш в алгоритме сравнения тут будет из-за меньшей длины хэша.

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

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

Невозможен частичный поиск.

Вывод - полнотекстовый поиск тут предоставляет большую гибкость и функциональность, задача поиска по большим текстам на равенство достаточно редкая.
32 Вафель
 
16.11.16
17:02
Так хэш можно и самому сделать, не нужно платформу ждать
33 MrStomak
 
16.11.16
17:09
(32) Нужно тогда будет вручную предусматривать коллизии, т.е. хэш не обладает уникальностью, нужно выполнять поиск по хэшу, потом догонять сравнение уже по исходным полям, удаляя оттуда ошибочные записи из-за дублей хэша.

Всё это конечно можно сделать, но в реальности зачем это применять, не совсем понятно. Точнее как - кейс из (0) как раз может быть ускорен таким образом, но есть и более простые способы оптимизировать такой поиск...
34 H A D G E H O G s
 
16.11.16
17:55
(31) Ну вот отлично, ты понял :-)
Полнотекстовый поиск работает для текстов или и для бинарных данных?
35 Вафель
 
16.11.16
17:56
(33) А можно справочник замутить тогда, где хэш будет - гуид )))
36 H A D G E H O G s
 
16.11.16
17:57
(31) nvarchar храниться в блоб объектах при любом своем размере.
37 H A D G E H O G s
 
16.11.16
18:04
(31) Ну и как плюс - можно вообще не записывать новые сырые данные, если их хэш не поменялся. Что до коллизий - их вероятность крайне мала, их можно отслеживать но вот что делать при их возникновении - мне не понятно.
38 MrStomak
 
16.11.16
20:04
(34) Уж не знаю ли, можно ли заставить поднотекстовый поиск индексировать двоичные данные, но смысла в этом не вижу никакого. Сохранится одно большое слово и места будет занимать в несколько раз больше, чем сами двоичные данные.

(36) Ну нет же! Тогда НайтиПоКоду работал бы через задницу. nvarchar(n) хранит себя в строке данных, nvarchar(max) по умолчанию - тоже, если не превысит 8Кб или для таблицы явно не задано свойство хранить его снаружи.

(37) Ну это уже первая нормальная форма, или вторая - не помню. Понятно, что любые повторяющиеся значения имеет смысл хранить в отдельной таблице.

Вероятность коллизий, понятно, зависит от алгоритма, на таблицах с миллионами записей получать дубли более чем реально. Делать с ними то же, что движок ms sql делает при hash match - найденные по хэшу записи дополнительно отфильтровать на совпадение "сырых", как ты говоришь, полей.
39 EvgeniuXP
 
16.11.16
20:44
У меня фотки быстро одинаковые ищет если присвоена другому сотруднику, а тут "представление" с типом строка длиной 500 долго :) и в 3ххх :)
Пользователь не знает, чего он хочет, пока не увидит то, что он получил. Эдвард Йодан