Полнотекстовый поиск в 1С. №1 Грабли в динамических списках

18.07.20

Задачи пользователя - Поиск данных

+145 –

Полнотекстовый поиск в 1С и все что с этим связано. Часть №1: особенности работы в динамических списках.

Найти, найти, найти

Поиск - одна из самых важных задач, которую решает платформа 1С. Чем больше размер базы, массив данных в ней, тем острее эта задача.

Стандартные возможности поиска средствами СУБД (будь это файловая база или SQL Server, PostgreSQL) не всегда работают эффективно, а уж тем более не могут удовлетворять условиям гибкого поиска по текстовому содержимому объектов. Да, поиск по индексированным полям решает множество задач, но вот гибкий поиск по текстовому содержимому на уровне СУБД не всегда работает на нужном уровне, особенно если речь идет о платформе 1С. Тут на помощь приходит полнотекстовый поиск платформы!

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

Ранее на эту тему публиковался инструмент "Мастер полнотекстового поиска", с помощью которого можно управлять настройками полнотекстового индекса и выполнять некоторые расширенные действия. Теперь пришло время для новых публикаций, где мы глубже копнем в теорию и практику использования полнотекстового индекса и даже выйдем немного за границы платформы. Но всему свое время.

Это первая часть публикации по этой теме. Появление продолжения будет зависеть от Вас. Будет интерес - будет и материал :)

И так, на старт, внимание....

Марш! Начнем с проблемы

Вот простая ситуация. В информационной базе создано почти 1 миллион документов "Заказ клиента". Это не плохо и не хорошо само по себе. Менеджеры по продажам каждый день работают со списком заказов, ищут в нем значения по различным полям, подбирают заказы в реализации или отчеты для отборов. В общем, поиск заказов клиентов - операция, которая выполняется даже чаще, чем их создание.

Если база в каком-то смысле "запущена" и не обслуживается в полной мере, то полнотекстовый поиск в ней может быть просто недоступен. Например, он может быть включен, но регламентные задания обновления и слияния полнотекстового индекса отключены. Или же использование полнотекстового индекса полностью выключено. А бывает еще хуже - полнотекстовый индекс используется, задания обновления индекса не включены, но при этом есть неактуальный индекс многолетней давности. В итоге поиск работает, но не находит все значения.

В списке заказов клиента поиск выполняется несколькими способами (чаще всего). Например, нужно найти заказы клиента, у которых в номере есть "85245" и имя клиента содержит слово "Сириус". Вот как это может выглядеть при выключенном / нерабочем полнотекстовом поиске:

По нажатию Ctrl+F попадаем в поле поиска (обычно справа вверху) и набираем нужное значение.

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

Выглядит достаточно удобно, т.к. искомые значения вводим в одно поле и ждем результата. Да и скорость вроде бы нормальная. Зачем вообще полнотекстовый поиск? К этому мы вернемся чуть позже.

Выделяем нужную колонку и после нажатия Alt+F ищем по нужному значению.

Альтернативный способ, который раньше был основным и вызывался через Ctrl+F - это поиск значений по отдельным колонкам. Да, раньше не было единого поля поиска над списком, но я думаю Вы и так знаете. Вот так это выглядит.

Этот способ визуально даже быстрее предыдущего. Далее мы также разберем почему. Полнотекстовый индекс в таком варианте никак не используется.

Есть и другие способы поиска (через настройку списка, например), но сейчас это не принципиально. Поэтому рассматривать их не будем.

И так, у нас есть два способа поиска, которые на первый взгляд работают быстро и эффективно и, что самое главное, не требуют настройки и обслуживания полнотекстового индекса. Все операции поиска выполняет СУБД. Но, прежде чем радоваться, давайте проверим а что там на уровне базы данных происходит.

Пример №1: Ищем с помощью единого поля поиска

В первом случае, когда мы выполняли поиск через единое поле ввода, платформа 1С сгенерировала очень интересные запросы к базе данных. Да, их было несколько и они очень объемные. Оставил комментарии в той части, которая важна для нашей темы.

Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №1

SELECT TOP 25
    T1._IDRRef,
    T1._Marked,
    T1._Number,
    T1._Date_Time,
    T1._Posted,
    T1._Fld15316RRef,
    T1._Fld15253RRef,
    T1._Fld15257RRef,
    T1._Fld15258RRef,
    T1._Fld15259,
    T1._Fld15283RRef,
    T1._Fld15296RRef,
    CASE WHEN (T1._Posted = 0x00) THEN 0x08 ELSE ISNULL(T2._Fld34485_TYPE,0x08) END,
    CASE WHEN (T1._Posted = 0x00) THEN 0x000004A6 ELSE ISNULL(T2._Fld34485_RTRef,0x000004A6) END,
    CASE WHEN (T1._Posted = 0x00) THEN 0x00000000000000000000000000000000 ELSE ISNULL(T2._Fld34485_RRRef,@P1) END,
    CASE WHEN (T1._Posted = 0x00) THEN 0x00 WHEN (T2._Fld34486 <> @P2) AND (@P3 > T2._Fld34486) THEN 0x01 ELSE 0x00 END,
    CASE WHEN T1._Fld15316RRef IN
(SELECT TOP 1
        T7._IDRRef AS Q_001_F_000RRef
    FROM dbo._Reference311 T7
    WHERE (T7._Fld1551 = @P4)
    ORDER BY T7._Fld8188) THEN @P5 WHEN T1._Fld15316RRef IN
(SELECT TOP 1
        T8._IDRRef AS Q_002_F_000RRef
    FROM dbo._Reference311 T8
    WHERE (T8._Fld1551 = @P6)
    ORDER BY T8._Fld8188 DESC) THEN @P7 ELSE @P8 END,
    ISNULL(CAST(T2._Fld34488 AS NUMERIC(3, 0)),@P9),
    ISNULL(CAST(T2._Fld34490 AS NUMERIC(3, 0)),@P10),
    ISNULL(CAST(T2._Fld34492 AS NUMERIC(3, 0)),@P11),
    ISNULL(T2._Fld34486,@P12),
    ISNULL(T2._Fld43374,0x00),
    T3._Fld120342
FROM dbo._Document572 T1 -- Документ.ЗаказКлиента
    LEFT OUTER JOIN dbo._InfoRg34483 T2 -- РегистрСведений.СостоянияЗаказовКлиентов
    ON ((T2._Fld34484_TYPE = 0x08 AND T2._Fld34484_RTRef = 0x0000023C AND T2._Fld34484_RRRef = T1._IDRRef)) AND (T2._Fld1551 = @P13)
    LEFT OUTER JOIN dbo._InfoRg34599 T3 -- РегистрСведений.СостоянияЭД
    ON ((T3._Fld34600_TYPE = 0x08 AND T3._Fld34600_RTRef = 0x0000023C AND T3._Fld34600_RRRef = T1._IDRRef)) AND (T3._Fld1551 = @P14)
    LEFT OUTER JOIN dbo._Reference47 T4 -- Справочник.Валюты
    ON (T1._Fld15258RRef = T4._IDRRef) AND (T4._Fld1551 = @P15)
    LEFT OUTER JOIN dbo._Reference260 T5 -- Справочник.Партнеры
    ON (T1._Fld15253RRef = T5._IDRRef) AND (T5._Fld1551 = @P16)
    LEFT OUTER JOIN dbo._Reference355 T6 -- Справочник.СделкиСКлиентами
    ON (T1._Fld15257RRef = T6._IDRRef) AND (T6._Fld1551 = @P17)
WHERE (
        ((T1._Fld1551 = @P18) -- Отбор по разделителю основной таблицы
        -- Поиск по вхождению в строковые поля по части строки поиска - "Сириус"
        AND ((T4._Description LIKE @P19 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
            OR (T1._Number LIKE @P20 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
            OR (T5._Description LIKE @P21 ESCAPE ''/'')  -- Поиск по вхождению в наименование Партеров
            OR (T3._Fld120342 LIKE @P22 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
            OR (T6._Description LIKE @P23 ESCAPE ''/''))
        ) -- Поиск по вхождению в наименование СделкиСКлиентами
        -- Поиск по вхождению в строковые поля по части строки поиска - "85245"
        AND (
            (T12._Description LIKE @P24 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P25 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P26 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P27 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                -- Поиск по полю ПроцентДолга регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P28) >= @P29)
                    AND (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P30) < @P31)
                -- Поиск по полю ПроцентОплаты регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P32) >= @P33) 
                    AND (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P34) < @P35) 
                -- Поиск по полю ПроцентОтгрузки регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P36) >= @P37) 
                    AND (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P38) < @P39) 
                OR (T14._Description LIKE @P40 ESCAPE ''/'') -- Поиск по вхождению в наименование СделкиСКлиентами
                -- Поиск по полю СуммаДокумента документа ЗаказКлиента. Значение либо больше искомого числа (или равно) или меньше.
                OR (T9._Fld15259 >= @P41) 
                    AND (T9._Fld15259 < @P42)
        )
    ) 
    -- Отбор по дате документа
    AND T1._Date_Time = @P43 
    -- Отбор по ссылке динамического списка
    AND T1._IDRRef >= @P44
ORDER BY (T1._Date_Time), (T1._IDRRef)
OPTION (FAST 1)

Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №2

SELECT TOP 25
    T1._IDRRef,
    T1._Marked,
    T1._Number,
    T1._Date_Time,
    T1._Posted,
    T1._Fld15316RRef,
    T1._Fld15253RRef,
    T1._Fld15257RRef,
    T1._Fld15258RRef,
    T1._Fld15259,
    T1._Fld15283RRef,
    T1._Fld15296RRef,
    CASE WHEN (T1._Posted = 0x00) THEN 0x08 ELSE ISNULL(T2._Fld34485_TYPE,0x08) END,
    CASE WHEN (T1._Posted = 0x00) THEN 0x000004A6 ELSE ISNULL(T2._Fld34485_RTRef,0x000004A6) END,
    CASE WHEN (T1._Posted = 0x00) THEN 0x00000000000000000000000000000000 ELSE ISNULL(T2._Fld34485_RRRef,@P1) END,
    CASE WHEN (T1._Posted = 0x00) THEN 0x00 WHEN (T2._Fld34486 <> @P2) AND (@P3 > T2._Fld34486) THEN 0x01 ELSE 0x00 END,
    CASE WHEN T1._Fld15316RRef IN
(SELECT TOP 1
        T7._IDRRef AS Q_001_F_000RRef
    FROM dbo._Reference311 T7
    WHERE (T7._Fld1551 = @P4)
    ORDER BY T7._Fld8188) THEN @P5 WHEN T1._Fld15316RRef IN
(SELECT TOP 1
        T8._IDRRef AS Q_002_F_000RRef
    FROM dbo._Reference311 T8
    WHERE (T8._Fld1551 = @P6)
    ORDER BY T8._Fld8188 DESC) THEN @P7 ELSE @P8 END,
    ISNULL(CAST(T2._Fld34488 AS NUMERIC(3, 0)),@P9),
    ISNULL(CAST(T2._Fld34490 AS NUMERIC(3, 0)),@P10),
    ISNULL(CAST(T2._Fld34492 AS NUMERIC(3, 0)),@P11),
    ISNULL(T2._Fld34486,@P12),
    ISNULL(T2._Fld43374,0x00),
    T3._Fld120342
FROM dbo._Document572 T1 -- Документ.ЗаказКлиента
    LEFT OUTER JOIN dbo._InfoRg34483 T2 -- РегистрСведений.СостоянияЗаказовКлиентов
    ON ((T2._Fld34484_TYPE = 0x08 AND T2._Fld34484_RTRef = 0x0000023C AND T2._Fld34484_RRRef = T1._IDRRef)) AND (T2._Fld1551 = @P13)
    LEFT OUTER JOIN dbo._InfoRg34599 T3 -- РегистрСведений.СостоянияЭД
    ON ((T3._Fld34600_TYPE = 0x08 AND T3._Fld34600_RTRef = 0x0000023C AND T3._Fld34600_RRRef = T1._IDRRef)) AND (T3._Fld1551 = @P14)
    LEFT OUTER JOIN dbo._Reference47 T4 -- Справочник.Валюты
    ON (T1._Fld15258RRef = T4._IDRRef) AND (T4._Fld1551 = @P15)
    LEFT OUTER JOIN dbo._Reference260 T5 -- Справочник.Партнеры
    ON (T1._Fld15253RRef = T5._IDRRef) AND (T5._Fld1551 = @P16)
    LEFT OUTER JOIN dbo._Reference355 T6 -- Справочник.СделкиСКлиентами
    ON (T1._Fld15257RRef = T6._IDRRef) AND (T6._Fld1551 = @P17)
WHERE (
        (
            (T9._Fld1551 = @P18) -- Отбор по разделителю основной таблицы
            -- Поиск по вхождению в строковые поля по части строки поиска - "Сириус"
            AND ((T12._Description LIKE @P19 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P20 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P21 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P22 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                OR (T14._Description LIKE @P23 ESCAPE ''/'')) -- Поиск по вхождению в наименование СделкиСКлиентами
            )
        -- Поиск по вхождению в строковые поля по части строки поиска - "85245"
        AND (
            (T12._Description LIKE @P24 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P25 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P26 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P27 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                -- Поиск по полю ПроцентДолга регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P28) >= @P29)
                    AND (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P30) < @P31)
                -- Поиск по полю ПроцентОплаты регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P32) >= @P33) 
                    AND (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P34) < @P35) 
                -- Поиск по полю ПроцентОтгрузки регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P36) >= @P37) 
                    AND (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P38) < @P39) 
                OR (T14._Description LIKE @P40 ESCAPE ''/'') -- Поиск по вхождению в наименование СделкиСКлиентами
                -- Поиск по полю СуммаДокумента документа ЗаказКлиента. Значение либо больше искомого числа (или равно) или меньше.
                OR (T9._Fld15259 >= @P41) 
                    AND (T9._Fld15259 < @P42)
        )
    ) 
    -- Отбор по дате документа
    AND T1._Date_Time = @P43 
    -- Отбор по ссылке динаического списка
    AND T1._IDRRef < @P44
ORDER BY (T1._Date_Time) DESC, (T1._IDRRef) DESC
OPTION
(FAST 1)

Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №3

SELECT TOP 25
T9._IDRRef,
T9._Marked,
T9._Number,
T9._Date_Time,
T9._Posted,
T9._Fld15316RRef,
T9._Fld15253RRef,
T9._Fld15257RRef,
T9._Fld15258RRef,
T9._Fld15259,
T9._Fld15283RRef,
T9._Fld15296RRef,
CASE WHEN (T9._Posted = 0x00) THEN 0x08 ELSE ISNULL(T10._Fld34485_TYPE,0x08) END,
CASE WHEN (T9._Posted = 0x00) THEN 0x000004A6 ELSE ISNULL(T10._Fld34485_RTRef,0x000004A6) END,
CASE WHEN (T9._Posted = 0x00) THEN 0x00000000000000000000000000000000 ELSE ISNULL(T10._Fld34485_RRRef,@P1) END,
CASE WHEN (T9._Posted = 0x00) THEN 0x00 WHEN (T10._Fld34486 <> @P2) AND (@P3 > T10._Fld34486) THEN 0x01 ELSE 0x00 END,
CASE WHEN T9._Fld15316RRef IN
(SELECT TOP 1
T15._IDRRef AS Q_001_F_000RRef
FROM dbo._Reference311 T15
WHERE (T15._Fld1551 = @P4)
ORDER BY T15._Fld8188) THEN @P5 WHEN T9._Fld15316RRef IN
(SELECT TOP 1
T16._IDRRef AS Q_002_F_000RRef
FROM dbo._Reference311 T16
WHERE (T16._Fld1551 = @P6)
ORDER BY T16._Fld8188 DESC) THEN @P7 ELSE @P8 END,
ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P9),
ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P10),
ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P11),
ISNULL(T10._Fld34486,@P12),
ISNULL(T10._Fld43374,0x00),
T11._Fld120342
FROM dbo._Document572 T9 -- Документ.ЗаказКлиента
    LEFT OUTER JOIN dbo._InfoRg34483 T10 -- РегистрСведений.СостоянияЗаказовКлиентов
    ON ((T10._Fld34484_TYPE = 0x08 AND T10._Fld34484_RTRef = 0x0000023C AND T10._Fld34484_RRRef = T9._IDRRef)) AND (T10._Fld1551 = @P13)
    LEFT OUTER JOIN dbo._InfoRg34599 T11 -- РегистрСведений.СостоянияЭД
    ON ((T11._Fld34600_TYPE = 0x08 AND T11._Fld34600_RTRef = 0x0000023C AND T11._Fld34600_RRRef = T9._IDRRef)) AND (T11._Fld1551 = @P14)
    LEFT OUTER JOIN dbo._Reference47 T12 -- Справочник.Валюты
    ON (T9._Fld15258RRef = T12._IDRRef) AND (T12._Fld1551 = @P15)
    LEFT OUTER JOIN dbo._Reference260 T13 -- Справочник.Партнеры
    ON (T9._Fld15253RRef = T13._IDRRef) AND (T13._Fld1551 = @P16)
    LEFT OUTER JOIN dbo._Reference355 T14 -- Справочник.СделкиСКлиентами
    ON (T9._Fld15257RRef = T14._IDRRef) AND (T14._Fld1551 = @P17)
WHERE (
        (
            (T9._Fld1551 = @P18) -- Отбор по разделителю основной таблицы
            -- Поиск по вхождению в строковые поля по части строки поиска - "Сириус"
            AND ((T12._Description LIKE @P19 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P20 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P21 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P22 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                OR (T14._Description LIKE @P23 ESCAPE ''/'')) -- Поиск по вхождению в наименование СделкиСКлиентами
            )
        -- Поиск по вхождению в строковые поля по части строки поиска - "85245"
        AND (
            (T12._Description LIKE @P24 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P25 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P26 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P27 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                -- Поиск по полю ПроцентДолга регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P28) >= @P29)
                    AND (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P30) < @P31)
                -- Поиск по полю ПроцентОплаты регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P32) >= @P33) 
                    AND (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P34) < @P35) 
                -- Поиск по полю ПроцентОтгрузки регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P36) >= @P37) 
                    AND (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P38) < @P39) 
                OR (T14._Description LIKE @P40 ESCAPE ''/'') -- Поиск по вхождению в наименование СделкиСКлиентами
                -- Поиск по полю СуммаДокумента документа ЗаказКлиента. Значение либо больше искомого числа (или равно) или меньше.
                OR (T9._Fld15259 >= @P41) 
                    AND (T9._Fld15259 < @P42)
        )
    ) 
    -- Отбор по дате документа
    AND T9._Date_Time > @P43
ORDER BY (T9._Date_Time), (T9._IDRRef)
OPTION (FAST 1)

Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №4

SELECT TOP 25
    T9._IDRRef,
    T9._Marked,
    T9._Number,
    T9._Date_Time,
    T9._Posted,
    T9._Fld15316RRef,
    T9._Fld15253RRef,
    T9._Fld15257RRef,
    T9._Fld15258RRef,
    T9._Fld15259,
    T9._Fld15283RRef,
    T9._Fld15296RRef,
    CASE WHEN (T9._Posted = 0x00) THEN 0x08 ELSE ISNULL(T10._Fld34485_TYPE,0x08) END,
    CASE WHEN (T9._Posted = 0x00) THEN 0x000004A6 ELSE ISNULL(T10._Fld34485_RTRef,0x000004A6) END,
    CASE WHEN (T9._Posted = 0x00) THEN 0x00000000000000000000000000000000 ELSE ISNULL(T10._Fld34485_RRRef,@P1) END,
    CASE WHEN (T9._Posted = 0x00) THEN 0x00 WHEN (T10._Fld34486 <> @P2) AND (@P3 > T10._Fld34486) THEN 0x01 ELSE 0x00 END,
    CASE WHEN T9._Fld15316RRef IN
(SELECT TOP 1
        T15._IDRRef AS Q_001_F_000RRef
    FROM dbo._Reference311 T15
    WHERE (T15._Fld1551 = @P4)
    ORDER BY T15._Fld8188) THEN @P5 WHEN T9._Fld15316RRef IN
(SELECT TOP 1
        T16._IDRRef AS Q_002_F_000RRef
    FROM dbo._Reference311 T16
    WHERE (T16._Fld1551 = @P6)
    ORDER BY T16._Fld8188 DESC) THEN @P7 ELSE @P8 END,
    ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P9),
    ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P10),
    ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P11),
    ISNULL(T10._Fld34486,@P12),
    ISNULL(T10._Fld43374,0x00),
    T11._Fld120342
FROM dbo._Document572 T9 -- Документ.ЗаказКлиента
    LEFT OUTER JOIN dbo._InfoRg34483 T10 -- РегистрСведений.СостоянияЗаказовКлиентов
    ON ((T10._Fld34484_TYPE = 0x08 AND T10._Fld34484_RTRef = 0x0000023C AND T10._Fld34484_RRRef = T9._IDRRef)) AND (T10._Fld1551 = @P13)
    LEFT OUTER JOIN dbo._InfoRg34599 T11 -- РегистрСведений.СостоянияЭД
    ON ((T11._Fld34600_TYPE = 0x08 AND T11._Fld34600_RTRef = 0x0000023C AND T11._Fld34600_RRRef = T9._IDRRef)) AND (T11._Fld1551 = @P14)
    LEFT OUTER JOIN dbo._Reference47 T12 -- Справочник.Валюты
    ON (T9._Fld15258RRef = T12._IDRRef) AND (T12._Fld1551 = @P15)
    LEFT OUTER JOIN dbo._Reference260 T13 -- Справочник.Партнеры
    ON (T9._Fld15253RRef = T13._IDRRef) AND (T13._Fld1551 = @P16)
    LEFT OUTER JOIN dbo._Reference355 T14 -- Справочник.СделкиСКлиентами
    ON (T9._Fld15257RRef = T14._IDRRef) AND (T14._Fld1551 = @P17)
WHERE (
        (
            (T9._Fld1551 = @P18) -- Отбор по разделителю основной таблицы
            -- Поиск по вхождению в строковые поля по части строки поиска - "Сириус"
            AND ((T12._Description LIKE @P19 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P20 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P21 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P22 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                OR (T14._Description LIKE @P23 ESCAPE ''/'')) -- Поиск по вхождению в наименование СделкиСКлиентами
            )
        -- Поиск по вхождению в строковые поля по части строки поиска - "85245"
        AND (
            (T12._Description LIKE @P24 ESCAPE ''/'') -- Поиск по вхождению в наименование Валюты
                OR (T9._Number LIKE @P25 ESCAPE ''/'') -- Поиск по вхождению в номер заказа клиента
                OR (T13._Description LIKE @P26 ESCAPE ''/'') -- Поиск по вхождению в наименование Партеров
                OR (T11._Fld120342 LIKE @P27 ESCAPE ''/'') -- Поиск по вхождению в поле ПредставлениеСостояния
                -- Поиск по полю ПроцентДолга регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P28) >= @P29)
                    AND (ISNULL(CAST(T10._Fld34492 AS NUMERIC(3, 0)),@P30) < @P31)
                -- Поиск по полю ПроцентОплаты регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P32) >= @P33) 
                    AND (ISNULL(CAST(T10._Fld34488 AS NUMERIC(3, 0)),@P34) < @P35) 
                -- Поиск по полю ПроцентОтгрузки регистра СостоянияЗаказовКлиентов. Значение либо больше искомого числа (или равно) или меньше.
                OR (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P36) >= @P37) 
                    AND (ISNULL(CAST(T10._Fld34490 AS NUMERIC(3, 0)),@P38) < @P39) 
                OR (T14._Description LIKE @P40 ESCAPE ''/'') -- Поиск по вхождению в наименование СделкиСКлиентами
                -- Поиск по полю СуммаДокумента документа ЗаказКлиента. Значение либо больше искомого числа (или равно) или меньше.
                OR (T9._Fld15259 >= @P41) 
                    AND (T9._Fld15259 < @P42)
        )
    ) 
    -- Отбор по дате документа
    AND T9._Date_Time < @P43
ORDER BY (T9._Date_Time) DESC, (T9._IDRRef) DESC
OPTION (FAST 1)

И так, платформа 1С сгенерировала аж 4 запроса для поиска по вхождению частей строки "Сириус 85245". Несмотря на то, что SQL-запросы похожи между собой, на самом деле они выполняют разную работу. Вот основные действия платформы в этом случае:

Платформа формирует SQL-запрос динамического списка и добавляет в него фильтры в соответствии с частями строки поиска.
Можно выделить основные отборы:
- Отбор по разделителю данных.
- Далее идет отбор по вхождению строки "Сириус" во все строковые поля, которые выводятся в динамический список. Причем это не только поля заказа клиента, но и других таблиц (регистра "Состояния заказов клиента", "Состояние ЭП" и др.
- После идет отбор по вхождению строки "85245" как в строковые поля списка (как в пункте выше), так и устанавливается отбор на числовые поля списка (процент долга, процент оплаты и др.). Причем на числовые поля отборы устанавливаются бессмысленные (значение в полях может быть меньше, равно или больше искомого значения). Есть другие варианты? :)
Далее в зависимости от 1 из 4 запросов устанавливается особый отбор:
- В первом запросе по определенной дате и ссылке, которая должна быть больше или равна определенного значения.
- Во втором запросе по дате и по ссылке, которая меньше определенного значения.
- Отбора по ссылке уже нет. Только по дате документа, которая должна быть больше определенного значения.
- Отбора по ссылке уже нет. Только по дате документа, которая должна быть меньше определенного значения.

Таким образом платформа 1С пытается разделить получение данных на части:

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

На тех этапах, когда в запросе имеется отбор на равенство конкретной дате документа все в принципе хорошо. Это селективный отбор и индекс по дате документа позволяет получать данные очень эффективно, никаких проблем. Но вот в остальных случаях, когда отбора на равенство по дате нет и вместо него появляется отбор по дате больше (или равно) и меньше определенного значения - тут начинается веселье. Взгляните на монструозный план запроса, который был сгенерирован СУБД для запроса, где дата документа больше определенного значения (см. запрос №3).

Страшный план запроса

Для конкретно нашего примера запрос "съел" весомые ресурсы:

Выполнялся примерно 8 секунд (CPU 8157 мс).
Прочитаны все записи таблицы заказов клиентов.
Использовал 10119361 страниц памяти (reads). А если вспомнить что каждая страница 8 КБ, то...

В общем, как видно стандартный поиск в списках через единое поле ввода может создавать тяжелые по использованию ресурсов запросы, которые могут поспорить со многими тяжелыми аналитически отчетами. Что самое удивительное - в нашем примере платформа 1С сгенерировала два тяжелых запроса: один с отбором по дате больше указанной даты документа, а второй с отбором меньше заданного значения. По затраченным ресурсам они практически не отличаются.

А ведь у нас искусственный пример, где поиск выполнялся одним пользователем. В многопользовательской среде все куда хуже!

Пример №2: Ищем с помощью отборов в отдельных колонках

Тут все значительно проще в части диагностики, чем в первом примере. Если мы устанавливаем отбор по двум колонкам через Altf+F, то платформа также генерирует 4 запроса по тем же принципам, что и выше. Но в этот раз отбор по искомым значениям в SQL-запросе иной. Не буду приводить все сформированные SQL-запросы, остановимся лишь на 1 самом "тяжелом".

Тяжелый запрос с отбором по 2 колонкам

Теперь текст запроса намного проще в части секции "WHERE".

SELECT TOP 25
    T7._IDRRef,
    T7._Marked,
    T7._Number,
    T7._Date_Time,
    T7._Posted,
    T7._Fld15316RRef,
    T7._Fld15253RRef,
    T7._Fld15257RRef,
    T7._Fld15258RRef,
    T7._Fld15259,
    T7._Fld15283RRef,
    T7._Fld15296RRef,
    CASE WHEN (T7._Posted = 0x00) THEN 0x08 ELSE ISNULL(T8._Fld34485_TYPE,0x08) END,
    CASE WHEN (T7._Posted = 0x00) THEN 0x000004A6 ELSE ISNULL(T8._Fld34485_RTRef,0x000004A6) END,
    CASE WHEN (T7._Posted = 0x00) THEN 0x00000000000000000000000000000000 ELSE ISNULL(T8._Fld34485_RRRef,@P1) END,
    CASE WHEN (T7._Posted = 0x00) THEN 0x00 WHEN (T8._Fld34486 <> @P2) AND (@P3 > T8._Fld34486) THEN 0x01 ELSE 0x00 END,
    CASE WHEN T7._Fld15316RRef IN
(SELECT TOP 1
        T11._IDRRef AS Q_001_F_000RRef
    FROM dbo._Reference311 T11
    WHERE (T11._Fld1551 = @P4)
    ORDER BY T11._Fld8188) THEN @P5 WHEN T7._Fld15316RRef IN
(SELECT TOP 1
        T12._IDRRef AS Q_002_F_000RRef
    FROM dbo._Reference311 T12
    WHERE (T12._Fld1551 = @P6)
    ORDER BY T12._Fld8188 DESC) THEN @P7 ELSE @P8 END,
    ISNULL(CAST(T8._Fld34488 AS NUMERIC(3, 0)),@P9),
    ISNULL(CAST(T8._Fld34490 AS NUMERIC(3, 0)),@P10),
    ISNULL(CAST(T8._Fld34492 AS NUMERIC(3, 0)),@P11),
    ISNULL(T8._Fld34486,@P12),
    ISNULL(T8._Fld43374,0x00),
    T9._Fld120342
FROM dbo._Document572 T7 -- Документ.ЗаказКлиента
    LEFT OUTER JOIN dbo._InfoRg34483 T8 -- РегистрСведений.СостоянияЗаказовКлиентов
    ON ((T8._Fld34484_TYPE = 0x08 AND T8._Fld34484_RTRef = 0x0000023C AND T8._Fld34484_RRRef = T7._IDRRef)) AND (T8._Fld1551 = @P13)
    LEFT OUTER JOIN dbo._InfoRg34599 T9 -- РегистрСведений.СостоянияЭД
    ON ((T9._Fld34600_TYPE = 0x08 AND T9._Fld34600_RTRef = 0x0000023C AND T9._Fld34600_RRRef = T7._IDRRef)) AND (T9._Fld1551 = @P14)
    LEFT OUTER JOIN dbo._Reference260 T10 -- Справочник.Партнеры
    ON (T7._Fld15253RRef = T10._IDRRef) AND (T10._Fld1551 = @P15)
WHERE (((T7._Fld1551 = @P16)  -- Отбор по разделителю основной таблицы
    AND (T10._Description LIKE @P17 ESCAPE ''/'')) -- Поиск по вхождению в наименование Партнеры
    AND (T7._Number LIKE @P18 ESCAPE ''/'')) -- Поиск по вхождению в номер Заказа клиента
    AND T7._Date_Time > @P19 -- Служебный отбор по дате для получения данных порциями (1 из 4 возможных отборов)
ORDER BY (T7._Date_Time), (T7._IDRRef)
OPTION (FAST 1)

Запрос стал проще и вместо страшных комбинаций условий отборов из предыдущего примера у нас появились конкретные условия по номеру документа и имени клиента (партнера). Запрос стал "кушать" меньше ресурсов:

Время выполнения примерно 2 секунды (CPU 2234 мс)
Прочитаны все записи таблицы заказов клиентов.
Общее количество прочитанных страниц 3514415.

Фактически, запрос выполняется в 4 раза быстрее, чем то что было выполнено в примере ранее. Но запрос все равно "съедает" непростительный объем ресурсов, особенно критичный для многопользовательской информационной системы.

Но можно ли такие операции поиска как-то оптимизировать?

Что обычно приходит в голову

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

Что это значит? Да очень просто:

Поиск через Ctrl+F и Alt+F больше невозможно выполнить. Стандартное поле поиска вверху списка убирают полностью.
Также запрещают использовать гибкий поиск через "Все действия -> Настроить список"
В шапку формы списка выводят несколько полей, по которым можно выполнять поиск. При этом отборы устанавливаются строго определенного типа (равно, начинается с...). Делается это для того, чтобы условия отборов могли использовать индексы. Как известно, условия "ПОДОБНО %<тут значение>%" не используют индексы.

Профит!

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

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

А вот и полнотекстовый поиск!

Как Вы могли увидеть, гибкий поиск по текстовому содержимому объектов обрабатывается СУБД не самым лучшим образом. И это нормально! Оператор поиска "LIKE" и не предназначен для такой задачи. На стороне СУБД для таких целей есть собственные движки полнотекстового поиска, которые платформа 1С не использует. Вместо этого фирма "1С" пошла своим путем и создала собственный движок для полнотекстового поиска данных, который мы и можем использовать для оптимизации подобного рода операций.

Тем более по умолчанию подразумевается, что поле поиска в тех же динамических списках будет использовать именно полнотекстовый поиск, а не возможности СУБД. Во многих базах (файловых и клиент-серверных) полнотекстовый индекс строится и обслуживается с помощью регламентных заданий и пользователи, разработчики, админы об этом могут просто не знать. Работает - не трогай, как говорится :).

Но чтобы убедиться, что построение и использование индекса полнотекстового поиска исправит наши тяжелые запросы выше - проведем эксперимент. Построим индекс полнотекстового поиска (я использовал инструмент "Мастер полнотекстового поиска", но никто не мешает Вам использовать стандартные обработки платформы). Размер индекса для всей базы с почти миллионом заказов клиента получился равным 7 ГБ.

Но рано радоваться, нужно проверить поможет ли полнотекстовый индекс в нашем конкретном случае.

Еще один эксперимент

А теперь выполним поиск через Ctrl+F как это делали ранее и посмотрим что на уровне базы данных. Повторный поиск через Alt+F делать не будем, т.к. поиск по конкретным колонкам всегда выполняется с помощью средств СУБД. А вот поиск через поле поиска - то что нужно.

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

Попробуем выполнить поиск только по части номера - "85245". Сразу скажу результат - снова ничего не изменилось. Платформа также настойчиво генерирует "страшные" SQL-запросы и игнорирует полнотекстовый индекс.

Идем дальше и через "Еще -> Изменить форму" оставляем в списке только колонки "Номер", "Дата", "Сумма", "Клиент". Эти поля 100% есть в составе заказа клиента и не получаются из сторонних таблиц, как например статусы заказа. Пытаемся выполнить поиск еще раз и...

Поиск отработал практически мгновенно! То, что нам нужно! При этом на стороне базы данных сформированы также 4 аналогичных запроса, но в них появились отборы по ссылкам. Это порции данных, которые были найдены с помощью полнотекстового поиска.

Запрос с фильтрами по результатам полнотекстового поиска

SELECT
    T1._IDRRef,
    T1._Date_Time
FROM dbo._Document572 T1
    LEFT OUTER JOIN dbo._InfoRg34483 T2
    ON ((T2._Fld34484_TYPE = 0x08 AND T2._Fld34484_RTRef = 0x0000023C AND T2._Fld34484_RRRef = T1._IDRRef)) AND (T2._Fld1551 = @P1)
    LEFT OUTER JOIN dbo._Reference260 T3
    ON (T1._Fld15253RRef = T3._IDRRef) AND (T3._Fld1551 = @P2)
WHERE ((T1._Fld1551 = @P3)) -- Отбор по разделителю основной таблицы
    AND ((T1._IDRRef IN (@P4)) -- Отбор по порции найденных ссылок
    -- Отбор по вхождению искомого значения в другие поля
    AND ((T1._Number LIKE @P5 ESCAPE ''/'') 
        OR (T3._Description LIKE @P6 ESCAPE ''/'')
        OR (T1._Fld15259 >= @P7) AND (T1._Fld15259 < @P8)
    ) 
    -- Отбор по другой порции найденных ссылок
    AND (T1._IDRRef IN (@P9, @P10, @P11)))

А вот если попробовать ввести строку поиска "Сириус 85245", то полнотекстовый поиск снова игнорируется и платформа опять (или снова) лезет с тяжелым запросом к базе данных.

Что все это значит?

В официальной документации сказано, что использование полнотекстового индекса в поиске динамического списка имеет следующие нюансы:

Полнотекстовый поиск должен быть включен для всех объектов, которые участвуют в запросе списка и могут использоваться в качестве основной таблицы. При этом все поля, выводимые в список, должны также быть с включенным полнотекстовым поиском.
Полнотекстовый индекс должен обслуживаться должным образом (не забыть настроить регл. задания).
Поиск выполняется по колонкам, которые отображаются в таблице.
Поиск по ссылочным полям выполняется по полям представления, которые также должны быть добавлены в полнотекстовый индекс.
Сначала выполняется поиск по основной таблице. К результатам полнотекстового поиска добавляются все непроиндексированные ссылки из основной таблицы. Результат полнотекстового поиска используется для отборов по ключевым полям.
При возникновении ошибок полнотекстового поиска режим поиска переключается на стандартных механизм, то есть с помощью средств баз данных.
Если есть отборы "Равно", то они в любом случае добавляются в финальный запрос с учетом отбора по результатам полнотекстового поиска.
Строка поиска разбивается на слова (максимум 20) и не должна превышать 1000 символов. Пробел и табуляция - разделители слов. Для каждого фрагмента создается свой набор условий по ИЛИ. Все фрагменты соединяются в И.

Часть из этих правил Вы могли увидеть в примерах выше, в т.ч. разбиение условий на фрагменты в запросах и так далее. Но почему в нашем случае полнотекстовый поиск не срабатывал, если указать имя партнера в строке поиска?

Причина для этого была только одна: в запросе имеются условия соединения и поля с регистрами сведений со статусами заказов и ЭП. Эти таблицы не проиндексированы. Причем эти поля использовались в запросе даже если убрать их из списка выводимых полей через "Изменить форму". Решение - упростить запрос в списке, удалив эти регистры, и все должно заработать. Ну или проиндексировать их.

Все так просто?

К сожалению, нет. Именно в этом примере нам повезло и мы нашли причину. Но бывают ситуации куда сложнее. Ситуация еще может усугубляться особенностями версии платформы и режимом совместимости. Например:

Платформа 8.3.12 с конфигурацией с совместимостью 8.3.4 в некоторых случаях может вообще не выполнять поиск. Также в этой версии не работает ограничение по метаданным для полнотекстового поиска. Если фильтр установлен, то возвращается пустой результат.
Также в одной из новых версий платформ не выполнялся полнотекстовый поиск по ссылочным полям, только по непосредственно полям основной таблицы.

Отлаживать такое поведение очень сложно и часто поиск причин выполняется по знаменитой методике "Метод тыка". А самое тяжелое здесь то, что даже типовые конфигурации не гарантируют, что в динамических списках будет работать полнотекстовый поиск. В примерах выше была конфигурация УТ 11. А если там все и работает корректно, то кто знает когда это может сломаться...

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

Только начало

Конечно, может стоило начать серию статей по полнотекстовому поиску в 1С с базовых теоретических знаний и примеров. Но на мой взгляд лучше сразу начать с хардкора.

В следующих статьях, если данная тема будет интересна сообществу, мы рассмотрим такие темы как:

Программная работа с полнотекстовым поиском
Сопровождение полнотекстового индекса и контроль его работы
Продвинутая отладка работы полнотекстового поиска в списка и других местах конфигурации
Как используется полнотекстовый поиск в типовых конфигурациях
Особенности обновления платформы в контексте полнотекстового поиска
Полнотекстовый поиск нестандартными средствами
Несколько кейсов по производительности платформы 1С при работе с полнотекстовым индексом
Как можно сломать полнотекстовый индекс на пустом месте.

А Вы используйте штатный полнотекстовый поиск 1С? Дайте знать в комментариях :) Любые вопросы, предложения по этой теме приветствуются :)

Другие ссылки

"Улучшение" поиска в динамических списках в 8.3.5
Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.
Очистка и обновление индекса полнотекстового поиска (регламентное задание)
Возвращение старого поиска в новых релизах Бухгалтерии предприятия 3.0
Полнотекстовый поиск по значениям реквизитов

Авторские разработки

Транслятор запросов 1С в SQL - инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.
Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.
Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.
История работы пользователей (отчет на СКД) - отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).
Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.
Технические проверки данных регистров бухгалтерии (отчет на СКД) - отчет для технических проверок данных бухгалтерских регистров.
Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.

Другие разработки

Помощник работы с идентификаторами объектов - инструмент для расширенного анализа идентификаторов объектов.
Информация о пользователях информационной базы (отчет на СКД) - два простых отчета по пользователям информационной базы и информации по ним.
Анализ производительности APDEX (бесплатный) - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.
Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.
Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.
Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.
Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С

полнотекстовый поиск администрирование разработка обновление платформы

+145 –

См. также

Быстрый поиск дублей в 1С с четким/нечетким поиском по любому сочетанию реквизитов/реквизитов таб. частей с отбором и быстрой заменой значений в ЛЮБЫХ базах 8.1-8.3 (УТ 10.3, БП 2, ЗУП 2.5, КА 1.1, УТ 11, БП 3, УНФ 1.6/3.0, КА 2, ЗУП 3 и т.д.)

Поиск данных Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Обработки помогут Вам легко и, главное, быстро (в 5 раз и быстрее штатной обработки 1С), выполнить поиск дублирующих данных в Ваших базах 1С на платформах 8.1-8.3. Это позволит уменьшить объем лишней информации в справочниках и документах, планах видов характеристик и др., упростит работу с данными пользователям. А так же можно, одним нажатием, узнать в каких ссылочных объектах есть вообще дубли! Понятное расположение команд и настроек, в сочетании с описанием и справкой, еще упростят процесс. А так же обновления Вы получаете бесплатно в течение года с момента приобретения данных обработок! (Обновление от 27.11.2023, версия 6.12)

10800 руб.

14.05.2012 159480 339 253

573

Универсальная коллекция. Класс-надстройка

Математика и алгоритмы Инструментарий разработчика Универсальные функции Поиск данных Программист Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

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

5 стартмани

25.09.2024 2522 1 Артано 14

Оптимизация поиска по ключевым словам с применением Clickhouse на примере номенклатуры.

Поиск данных Программист Платформа 1С v8.3 Россия Бесплатно (free)

В этой статье я хочу рассмотреть еще один кейс применения Clickhouse в связке с 1С - оптимизацию поиска в справочнике по ключевым словам. Здесь не будет готового решения, но будут описаны важные моменты, которые позволят легко применить данный кейс в реальности.

18.08.2024 2123 1cnik2 23

Обход объекта рекурсивно

Поиск данных Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Отображение и просмотр реквизитов справочника или документа - с бесконечным открытием подуровней.

1 стартмани

14.06.2024 3615 8 RustIG 29

Кто такая Мантикора?

Поиск данных Системный администратор Программист Платформа 1С v8.3 Россия Абонемент ($m)

Статья об опыте развертывания и интеграции с базой данных Manticore Search для быстрого полнотекстового поиска.

1 стартмани

30.11.2023 4968 andreysidor4uk 18

PowerOffice - обработка для поиска, просмотра и обработки данных.

Поиск данных Корректировка данных Пользователь Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

PowerOffice - обработка для поиска, просмотра и обработки данных для пользователей. Доступ к объектам на просмотр и редактирование данных определяется правами пользователя.

1 стартмани

05.06.2023 2411 26 PowerBoy 1

Получение ссылки по бинарной строке PostgreSQL или MSSQL

Поиск данных Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Получение ссылки в 1С по бинарной строке из PostgreSQL в виде строки формата bytea или из MSSQL в виде шестнадцатиричной строки. Кроме ссылочных объектов ссылки могут быть получены и для перечислений. Это может быть полезно при анализе логов журнала регистрации или СУБД.

1 стартмани

04.04.2023 3294 4 berserg 2

Поиск и замена значений многопоточно

Поиск данных Подбор и обработка объектов Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 Абонемент ($m)

Обработка для конфигураций на БСП, выполняет замену в несколько потоков. Только клиент-серверный вариант

2 стартмани

14.02.2023 5653 152 echo77 27

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. tormozit 7245 18.07.20 23:56 Сейчас в теме

Опечатка в SQL запросе №1
динаического -> динамического

2. PerlAmutor 155 19.07.20 08:19 Сейчас в теме

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

Я тут наткнулся еще на одну нерешенную задачку. У меня есть форма выбора с динамическим списком, причем поле там всего одно - строковое. При передаче в форму выбора параметра "ТекущаяСтрока" ничего не происходит, т.к. значение - не ссылочного типа, а строкового.

Как же найти в динамическом списке нужную строку и спозиционироваться на неё?

3. пользователь 19.07.20 08:39

(2) случаи, когда только перестроение индекса помогало - были. К сожалению, часто.

А какой там запрос в списке? Ссылку нельзя в запросе получить и сделать обязательной к получению? Тогда по неи и позиционироваться.

7. PerlAmutor 155 19.07.20 19:59 Сейчас в теме

(3) Там внешний источник данных, ссылок нет никаких, только строковый идентификатор в качестве уникального значения. От ссылочных полей отказался по той причине, что таблица периодически перестраивается и записи таблицы могут получить идентификаторы, которые день назад принадлежали другим записям. 1С все это дело пытается кэшировать и из-за этого возникают проблемы с получением представлений. Видим на экране одно, а внутри содержится другое. Искали одно, а получили другое.

10. пользователь 20.07.20 10:34

(7) тут все усложняется. Обычно позиционирование по ссылке выполняется. А по строке... Надо "химичить".

14. Yashazz 4801 21.07.20 00:54 Сейчас в теме

(7) Попробуйте поиграть с "Вид ключа" в режиме "Значение поля" и с "Поле ключа", например, в явном виде указать в качестве вида именно это строковое поле; тогда ТекущаяСтрока и на клиенте, и на сервере вернёт именно ключевую строку. Ну, естесссно, если строки уникальны и годятся на ключ. Если нет, тогда ставьте вид ключа "Номер строки" и выкручивайтесь через СКД дин.списка и её текущие настройки.
...сделать, что ли, об этом публикацию...

4. ivanov660 4592 19.07.20 09:39 Сейчас в теме

Согласен, напрягает сильно этот бизнес со своим поиском в динамических списках по "трем символам", возможности добавления полей через две точки, отборов, группировок и сортировок по не предназначенным полям. Иногда хочется установить формы отчетов с жесткими отборами и ограничением первые 50)

Ответить

5. пользователь 19.07.20 10:08

(4) воистину!

6. muskul 19.07.20 10:13 Сейчас в теме

Всегда были проблемы с этим поиском. то номенклатура не ищется то клиенты.

8. Yashazz 4801 19.07.20 22:00 Сейчас в теме

Юрию респект за хорошую статью, а инструменту платформы - категорическое "фу", проще своими силами эмулировать, чем штатное юзать.

9. bulpi 217 20.07.20 10:33 Сейчас в теме

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

11. пользователь 20.07.20 10:35

(9) я постараюсь переубедить в следующих публикациях.

Все таки использовать его можно и нужно.

12. user633166 12 20.07.20 13:01 Сейчас в теме

(11) Спасибо за детальный разбор, но соглашусь с (8) и (9) - уверенности в инструменте такие поиски причин, почему что-то не находится, хотя оно есть, не добавляют. И где "ждут тебя эти грабли"? Когда "прилетят"?

А следующую публикацию ждём...

16. Yashazz 4801 21.07.20 01:08 Сейчас в теме

(12) Да, если мы с уровня "слияние/обновление индексов и разница между ними" перейдём к тезаурусам, стоп-словам и вообще АОТЕЯ в 1С, то я "за" двумя руками!

13. пользователь 20.07.20 23:41

(0) Вот еще интересная публикация по этой теме: https://infostart.ru/public/1267438/

15. Yashazz 4801 21.07.20 00:57 Сейчас в теме

(13) Неее. Мне кажется, там решение частного случая в рамках документации...

И вообще, пока нет программных средств управления полнотекстовым, или хотя бы настройки индексации (словари, размеры порций, порядок слияния, размещение, я уж не говорю про шкалу релевантности, уровень шума и синтагматические связки), он остаётся вещью в себе и чёрным ящиком.
Ощущение, что портировали некую хрень, прикрутили к платформе, да сами не сильно в ней разобрались. Прям иногда интересно, что это было - Сфинкс, или что-то на основе Solr'a...

17. ITSun 22.07.20 15:58 Сейчас в теме

Очень детально и наглядная подача, спасибо за статью! +

18. omen3333 4 27.07.20 21:56 Сейчас в теме

Спасибо за статью.

Работал в фирме с двумя десятками УТшек, в двух из которых тоже была тысяча тысяч заказов, индекс полнотекстового поиска в каждой из таких баз весил > 25Гб. На время слияния индекс занимал ещё столько же места. Т.е. при одновременном слиянии индекса во всех базах, сервер периодически оставался без места на дисках. Долго пытались его облегчить, пришлось отключить. Но там старая платформа было, 8.3.12-13.

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

19. rukalico 14.03.21 12:41 Сейчас в теме

Не понятен момент -
А вот если попробовать ввести строку поиска "Сириус 85245", то полнотекстовый поиск снова игнорируется и платформа опять (или снова) лезет с тяжелым запросом к базе данных
По клиенту ведь включен полнотекстовый поиск, почему же в такому случае он все равно не срабатывает?

20. OstHusky 32 27.04.21 14:19 Сейчас в теме

В типовых конфигурациях есть, например, регистр сведений "НаличиеФайлов", он используется для отображения скрепки в списках всех документов, к которым можно присоединять файлы. У этого регистра выключено использование полнотекстового поиска, получается, что полнотекстовый поиск не будет работать в большинстве списках документов? Как-то странно со стороны 1С так делать или это не так? Регистр наличие файлов можно выбрать как основную таблицу списка, соответственно он должен быть включен для этого регистра.

21. scaramouche 12.08.21 11:14 Сейчас в теме

отличная статья! большое спасибо!

22. mephistofel 16 26.09.24 22:37 Сейчас в теме

Спасибо! Стало понятнее что это за зверь и что с ним делать

Оставьте свое сообщение

E-mail:

Автор:

Инфобот (Infostart)

Рейтинг: 26007

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 1056842

Создание 18.07.20 22:00

Обновление 18.07.20 22:00

Статистика:

Просмотры 31185

Загрузки 0

Рейтинг 145

Комментарии 22

Характеристики:

Код открыт Да

Рубрики Поиск данных

Кому Системный администратор ,
Программист ,
Стажер

Тип файла Нет файла

Платформа Платформа 1С v8.3

Конфигурация Конфигурации 1cv8

Операционная система Не имеет значения

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)