Привет всем! Выручайте - я совершенно не силен в вопросах ускорения:
есть справочник с около 1,5 записей - товары. У них оригинальные артикулы. Остальное (названия) могу быть совпадающими. Заявки от клиентов приходят в электронном виде в свободной форме. Позиций в заявках - от 100 до 1000. Так вот вопрос: как лучше поиск вести по справочнику - по вхождению подстроки (номер в заявке клиента) в артикул номенклутары, или регистр забацать с содержанием артикулов - что быстрее работает?

Карандаш М артикул 1
Карандаш М артикул 2
Карандаш М артикул 3
Карандаш М артикул 4

?

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

да, примерно так. Но точнее вот так:
Карандаш М артикул 1234111
Карандаш М артикул 1234112
Карандаш М артикул 1234101

в заявке клиента будет карандащ М артикул 1234

а не проще ли полностью артикул набирать?

Если вынести 1234111 в отдельный инлексированный реквизит или в регистр "соответсвий" то посик будет быстрее

да нет, наверное в моем случае "какая разница в какой таблице"

а, недочитал.
Если у клиента 1234 то нет смысла - все равно подобно придется использовать

сделать унифицированную форму заявки с кодом товара
смотри в сторону РС НоменклатураКонтрагентов

(5) индексированные реквизиты помогли. Но когда база достигла 1,5 млн и они уже не помогают. Одна заявка от 17 до 60 минут грузится на виртуальном диске в РАМ памяти, процы под 100% (ну 25%)

Я к сожалению 400 раз обращаюсь с запросом подобно %артикул%. А как сделать чтоб сразу отобрать (в запрос передать перечень подстрок-артикулов)?

(10) :) Передать параметром таблицу

Потом ее содинить со спр через подобно

(12) пробую! Спасибо!

т.е всесто Где Спр.Артикул Подобно &Параметр

Выбрать Таб.ПодАртикул Поместить Заявка из &Таб Как Таб;
Выбрать Спр.Ссылка
внутренее соединение Таб
по Спр.Артикул Подобно Таб.ПодАртикул


Честно говоря, я думал что и сделано)

что так и сделано*

поправил
Выбрать Таб.ПодАртикул Поместить Заявка из &Таб Как Таб;
Выбрать Спр.Ссылка
внутренее соединение Заявка
по Спр.Артикул Подобно Заявка.ПодАртикул

не дает связать по ПОДОБНО, только равно

на форме зачем искать?
заполнение таб.части в заказ- пишется обработка и запросом

артикул в списке разве не быстро?

(18) не, я на форме тока из файла ексель читаю, потом таблицу с артикулами на сервер передал, а там уже 400 раз запрос через %подобно" сделал. Прошу не чморить. Но не знаю как.

ВЫБРАТЬ
   Номенклатура.Ссылка
ИЗ
   Справочник.Номенклатура КАК Номенклатура
ГДЕ
   Номенклатура.Артикул В(&СписокАртикулов)

(21) артикулы не полностью совпадают. - на 80-90% только совпадают.

так и сделай, выбери и проиндексируй Артикул как Строка(4) и потом на равенство
должен быть выигрыш, т.к. = сильно быстрее

если начало совпадает то мож так поможет:

ВЫБРАТЬ
   Номенклатура.Ссылка
ИЗ
   Справочник.Номенклатура КАК Номенклатура
ГДЕ
   ПОДСТРОКА(Номенклатура.Артикул, 1, 4) = &подстрАртикула

(23)(24) спасибо за идеи. Как же в списке когда находишься - жмешь найти (УФ) вводишь подстроку и через 10-15 секунд уже список из 10 товаров на морде высветился. Меня бы устроило.

База то всего ничего - 300 метров. Самописка из 2 справочников. Для выписки счетов. Может ее на SQL перенести? КОличество транзакций на запись в ней - фиг да нифига, а вот чтение - напряги...

Проанализируй продажи. Весь товар продается неравномерно. Создай индекс по продаваемости товара. Тот что чаще берут выводи первым в поиске и ссылайся в заказах на него. В 98% случаях будете попадать куда нужно, а 2% погрешность ввода - вам простят. Главное чтобы товар был на складе или для заказа у поставщика.
Если заявки ваших клиентов будут удовлетворяться на 90-95%, а не на 60-80, то и продажи возрастут.

Как еще один вариант, выбрать подстрок(наименования) + ссылку во временную таблицу и проиндексировать подстроку. Для поиска  использовать именно её, а потом подтягивать ссылки и остатки.

Феерично, связывать таблицы по Подобно
Может нужно в консерватории (заказах) артикулы подправить?

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

(29) такие случаи есть, в таком случае менеджеру предоставляется право выбора из 3 товаров. Выводится окно со списком найденных товаров и менеджер тыкает нужный.

(29) про феерию знаю, потому и пытаюсь уйти от нее. А про "решить в уме" - так здесь уже на логику нет задачек, вопрос "как быстрее найти 500 подстрок".

(0) решания два
1. Клиент шлет заказы в артикулах фирмы, поиск идет на =
2. Решение через полнотекстовый поиск

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

(32) ну видимо у Вас такая задача была. Так и идем к вебморде. Это финал будет. Но сейчас старт только.Хотят сами мочить заявки.

Я за полнотекстовый поиск

полнотекстовый, это = или подобно? я уже туплю

Какая конфигурация то ?

(35) http://v8.1c.ru/overview/Term_000000275.htm

(36) Моя. Справочник Номенклатура с реквизитами Артикул, Наименование и Справочник Контрагенты. И документ Коммерческое предложение. Все. А нуда - обработка Загрузка прайса.

Попробуй заменить в запросе "подобно" на два условия: Артикул >= "карандащ М артикул 1234" И Артикул < "карандащ М артикул 1234я". Мне так реально помогло на больших базах.

(39) хороший вариант

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

(30) Т.е. покупателю все равно?
Ну так может автоматизировать это дело?
Выбирать первое совпадающее?
Или менеджер, сплевывая через левое плечо, выбирает то первый товар, то второй?
На что он тратит свое время?
Поразгонять вас нужно всех...

1,5 млн. записей при наличии индексов - не проблема

попробуй клиент-серверный вариант, посмотри насколько быстрее будет работать

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

(41) Кстати достаточно интересный вариант, учитывая, что ограничений на скорость запись в базу нет. Именно так устроен ОЛАП.

(44) Клиент серверный на SQL уже после нового года с товарищем будем пробовать. Сейчас уже времени нет. Пока удалось только выяснить, что на 2-х ядерном старом проце (десктоппе) заявка грузится процентов на 20-40% быстрее, чем на мощном ноуте (4-х ядерном).

(41) Сейчас заказчик получил некую смесь методов - сначала (в течение 10 секунд подбирается большая часть товаров по полному соответствию артикулов, а потом если что-то не нашлось по условию "=", то начинает работать цикл с запросом "подобно". Вместо 1ч10мин получил 10 минут. ПОка неплохо. Буду смотреть в сторону (41) - усеченных артикулов.

(45) регистр не помог.

(43) ну если заявка из 400-500 строк грузится 1ч10мин, то для Вас это может быть и не проблема. "=" по сравнению с "подобно" примерно в 280 раз быстрее. Вот и надо получить скорость примерно как "=", а удобство, как "подобно". Если для Вас не проблема - посоветуйте решение.

(26)она что файловая? конечно на скуль и функцию поиска на сервер вынести

Советовать - не самому делать. Советую :)

Делаю регистр сведений с "АртикулЗаявки" (четыре символа артикула номенклатуры), "Приоритет" (число, например, статистика использования в заявках) и "Номенклатура" (ссылка на справочник).

Собираю в ТЗ значения из заявки покупателя и всё это в запрос. Единым запросом получаю все нужные значения для заполнения ТЧ документа.

Проблему (когда по артикулу заявки есть несколько позиций в справочнике) - игнорирую - это не мои проблемы :)

Решаю так (если обработка заявок покупателей - регалментная):
Пишу в ТЧ все найденные позиции, но: первая позиция - заполняю поля ТЧ полностью, "как положено". Остальные "аналоги" (сортированные по приоритету) - пишу следом, но без суммовых значений. Смысл?
Эта группа строк - для "отложенного" выбора нужной строки юзверу. Как?
Обработка ТЧ "Выбрать текущую строку из группы аналогичных" помогает юзверу сделать выбор. Как?
Используя текущую строку, выбираю все строки "группы аналогичных". "Группа" - это строки выше до позиции с ценой больше нуля(включая) и строки ниже до позиции с ценой больше нуля(исключая). Удаляю все строки "группы" кроме текущей. В текущую строку подставляю суммовые значения из первой строки "группы".

Типа как-то так.

(50) а у поля артикул точно стоит флажок индексирования, и в номенклатуре и в регистре?

(17) Позволяет. Нужно руками прописать произвольное условие или вовсе рукам в тексте.

если простая самописка можно вообще на несколько однотипных справочников разделить типа артикулы с 1 по 5 в одной таблице остальные в др. ну это если др. средства не помогут.
еще прямые запросы если скуль на 8-ке не писал, на 7.7 помогало

+ к (17) Я бы наверное от балды бы не стал писать

(ТС) Если избавишь от цикличного запроса, это даст существенное ускорение, даже при использовании ПОДОБНО.
Не в 400 раз конечно, но, возможно, в десятки.
Если результат будет не устраивать, толга придется думать а различных вариантах вспомогательных полей/таблиц специлаьно под быстрый поиск. Вариантов миллион, выбирать нужно, зная точно местные условия

(52) я наверное сам виноват, что не могу нормально изложить вопрос. Вопрос мой - не методологический, вопрос мой - технический. Потому что все ньюансы я здесь не опишу - это будет томик Пушкина. У меня например будут сложности с созданием коротких артикулов для поиска - в прайсе могут быть R123fa а в заявке 123f. Сегодня ночером выяснил. Т.е. вообще остается по подстроке. Коротких артикулов я не нарежу.

(57) от цикличного запроса на прямое соответствие я уже избавился - разом выбирается процентов 60-80% товаров. Остальное - циклом с запросом Подобно.
(56) А сам пробовал?

(59) "А ты сам пробовал?"
Ппц

Я еще должен доказать что я не верблюд

Как хочешь

если по первым буквам искать то индекс работает, если по вхождению, то смотреть в сторону полнотекстового индекса

(63) Про полнотекстовый поиск кстати хорошая альтернативная идея, без изобретания собственных колес

(офф) Честно говоря я в шоке от "заявка из 400-500 строк грузится 1ч10мин" :( Не понимаю, хоть убейте. Они там что забыли комп включить чтоли? :))
Я документы инвентаризации заполнял на две-три тысячи позиций (источник - файл dbf; соответствие - нечеткий поиск по наименованию с помощью StrMatch) за пару-тройку минут...

(55) я не умею прямые запросы делать.

А нельзя динамически формировать запрос?
Единственное придется учитывать превышение 256 таблиц.
ВЫБРАТЬ
&Артикул_1 КАК АртикулЗаявка,
СпрНом.Артикул,
СпрНом.Ссылка КАК Номенклатура
ИЗ Справочник.Номенклатура КАК СпрНом
ГДЕ &Артикул = ПОДСТРОКА(СпрНом.Артикул,1,<КоличествоЗнаков>)

(65) поиск по базе с каким ассортиментом был?

в запросе ошибка

(67) не, я не знаю
ПОДСТРОКА(СпрНом.Артикул,1,<КоличествоЗнаков>) - с единицы ли резать или может быть со второго знака, а может быть с третьего...

(39)(40) это аналог запроса
Артикул ПОДОБНО "карандащ М артикул 1234%"

(63) это как он работает? по какому индексу?
(58) заполняй а ля НоменклатураКонтрагентов

(3) а номенклатуру то какую в итоге в заявке укажешь по данному примеру?

(65) да и какая разница с какого источника грузить - я с экселя за 15 секунд все 500 позиций считал - а потом чисто поиск и подстановка

(73) раньше первую попавшуюся, теперь - на выбор менеджеру.

замени на подобно
в чем проблема
Главное запрос будет выполняться не 500 раз а 2 допустим.
а вообще это как-то странно. выбор ведь должен идти с начала или я ошибаюсь?

какая длина поля АРТИКУЛ ?

(76) про "выбор сначала" не совсем понял

(77) в прайсах длина от 7 до 20 знаков

попробуй зайти в конфигуратор и проиндексировать БД.

пробовал формировать динамически один большой запрос вместо кучи небольших ???

(81) Предлагаешь делать запрос
Выбрать чтото
из чегото
Где чтотоПодобно &Пар1
Объединить

Выбрать чтото
из чегото
Где чтотоПодобно &Пар2
Объединить
....
Выбрать чтото
из чегото
Где чтотоПодобно &Пар400
Объединить

Офигеть. Дайте две. Нет, Четыреста

(0) а вообще диски поставь другие. у нас поиск на подобно серии на 150 позиций по 3 млн серий выполняется секунд 30..

(81) в данном случае не поможет я думаю, потому как основной затык не в скорости ответа по каждому запросу.

"в прайсе могут быть R123fa а в заявке 123f."(тс)

(84)+ причем поиск осуществляется не по одной колонке в excel, а по 10

Не попробуешь не узнаешь

(80) да база то нулевая - я в пустую базу гружу пару прайсов по 600 000 позиций и несколько по 100 000, и после этого пытаюсь заявку загрузить. И все...

Сложно зайти в конфигуратор и переиндексировать БД?
может у тебя индексы кривые?

(89) да почему кривые то с чего? индексирую уже...

(89) Индексирование здесь не поможет. При поиске "подобно" внутри строки происходит скан таблицы, индекс не используется.