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

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

В справочнике содержаться 3-4 тыс элементов, понятно что запрос по поиску совпадений выполняется долго, подскажите можно ли ускорить запрос? что можно сделать, чтобы поиск выполнялся быстрее?

в индекс не попадаешь

(1) а его и не может быть, индекса - представление неограниченной длины.

Решение - вынести "использованные" телефоны в отдельный РС, где они будут храниться в индексированном поле ограниченной длины. И искать по нему перед записью, а не по ТЧ. В РЧ записывать при записи партнера

а если представление ограниченной длины, то можно просто индексирование включить у полей Тип и Представление.

(0) Можно попробовать полнотекстовый поиск.

(0) Почему должно быть понятно, что запрос выполняется долго?
Где Номер телефона и почты в запросе?
3-4 тысячи элементов это много?
Что творится?

(0) А давай использовать для поиска не Представление, и НомерТелефона (если мы говорим про подсистему КИ из БСП)?
Индекс по нему включил и всё, проблемы нет.

(3) Вот это плохой совет.
Если индексирование включить у "Тип" и "представление", то будет 2 индекса, которые не пересекаются.
Фактически СУБД сможет использовать для поиска только 1 из них.
Нужно самому выбирать наиболее селективный реквезит, т.е. "Представление" (но на самом деле - НомерТелефона =])

>ПартнерыКонтактнаяИнформация.Представление = &Представление

ужас!

хотя юзера со своими хотелками такие юзера...

(3) достаточно по типу... представление в 8.3.5 и далее можно менять программно.

(10) Представление - это реквизит табличной части. Строка(500).

(7) вообще да. Но, кстати, отбор по типу в запросе тут нах не нужен, раз там равенство.

(11) да лана, модуль магнагера справочника:
Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка)
бла-бла-бла
КонецПроцедуры

8.3.6.2152 если чё

Интересно, СУБД когда-нибудь допилят до хранения хэша поля, которое указал программер в дизайнере?

(13) Ты еще раз перечитай, чтоли - Представление - это реквизит табличной части конкретного справочника. Его так назвали. А могли назвать ПредставлениеКотороеНеФункцияПредставленияСправочникаЧтобыНиктоНеПерепутал. Но не стали.

(14) Не понял тебя, раскрой мысль

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

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

(14) Ну и его асинхронное обновление. И глобальные флаг у таблицы "ХешПоляПредставлениеАдресаАктуален". И искать уже по нему, а не по мегабайтам сырых данных.

(12)
Ну как бы да. Тут только есть чисто техническая возможность указать адрес в номере телефона и получить два разных типа на одном представлении... Так что на всякий случай лучше доотбирать тип...

(18) Это технически на порядок проще, чем полнотекстовый поиск.

(17) По моему ты чет не вкурил. Или я не понял твоих мыслей.

(19) если так будут делать, то их ни чего не спасет

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

(23) Какую задачу всё это будет решать? Поиск - а есть ли уже такое? Опиши сценарий использования, непонятно.

(24) Поиск по "сырому" полю. Для искомого значения строим хеш и ищем по колонке "хеш", которую можно (и нужно) проиндексировать. Ну а потом keylookup, что лучше чем scan.

Соединение по сырым полям 2-х таблиц. Вместо сырых полей подставляются поля с из хешем.

Да и сам алгоритм сравнения 2 х хешей занимает меньше ресурсного времени чем сравнение 2-х сырых данных.

(25) В чем принципиальное отличие от индекса, кроме невозможности использования условий на больше-меньше?

(25) Для keylookup нужно знать позицию строки в таблице. Где она будет? Как будет поддерживаться актуальность этой информации?

Мне лениво пытаться тебе объяснять. Я уже все объяснил и не понимаю, что тебе не понятно.

(30)
Ну сложно понять твою мысль.

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

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

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

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

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

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

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

Так хэш можно и самому сделать, не нужно платформу ждать

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

Всё это конечно можно сделать, но в реальности зачем это применять, не совсем понятно. Точнее как - кейс из (0) как раз может быть ускорен таким образом, но есть и более простые способы оптимизировать такой поиск...

(31) Ну вот отлично, ты понял :-)
Полнотекстовый поиск работает для текстов или и для бинарных данных?

(33) А можно справочник замутить тогда, где хэш будет - гуид )))

(31) nvarchar храниться в блоб объектах при любом своем размере.

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

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

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

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

Вероятность коллизий, понятно, зависит от алгоритма, на таблицах с миллионами записей получать дубли более чем реально. Делать с ними то же, что движок ms sql делает при hash match - найденные по хэшу записи дополнительно отфильтровать на совпадение "сырых", как ты говоришь, полей.

У меня фотки быстро одинаковые ищет если присвоена другому сотруднику, а тут "представление" с типом строка длиной 500 долго :) и в 3ххх :)