| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Поиск по контексту с помощью SQL запроса
Jioniro © (2005-09-22 11:47:00)Привет всем!!!
Имеется таблица Paradox с наименованиями товаров(String[254]).
Выполняю поиск по контексту с помощью запроса
SELECT Name FROM "Art.db" Art where
(UPPER(Name) LIKE ''%'+AnsiUpperCase(Edit1.Text)+'%'')
и результат вывожу в DbGrid. Запрос выполняется при каждом изменении
значения Edit1.Text.
Таблица имеет порядка 20000 записей. Как можно догадаться поиск выполняется с задержками
1-2 сек (при выполнении запроса).
Подскажите плз можно ли ускорить выполнение запроса или предложите другой
способ поиска по контексту.
Курдль (2005-09-22 15:54:00) [1]
> Как показала 3-х летняя практика необходим поиск по нескольким
> контекстам именно по наименованию товара и при каждом нажатии
> клавиши
Думаю, что без 3-хлетней практики не постичь мастерства одновременного нажатия клавиш в нескольких контекстах одновременно :)
Jioniro (2005-09-22 15:28:00) [2]> Курдль © (22.09.05 14:55) [31]
> Тогда в забытом мною фрагменте примера, указанного выше,
> следует подработать получение значения параметра Ассерt
> не одним поиском субстроки, а несколькими.
нормально сработало, вроде довольно быстро при 20000 записей! попробую если больше но думаю подойдёт!
Сенкс всем!!!
Sergey13 (2005-09-22 15:04:00) [3]2 [18] Курдль © (22.09.05 14:17)
> Это чье юзибилити утвердило?
Мое. На это указывает абревиатура в начале поста.
>Если прога открывается утром, выключается вечером, а ассортимент товара меняется раз в месяц - тогда и б БД нефиг лазить со своими запросами !
Вот с этим не спорю. Но автору надо "с помощью SQL запроса". 8-)
Курдль (2005-09-22 14:55:00) [4]
> Как показала 3-х летняя практика необходим поиск по нескольким
> контекстам именно по наименованию товара и при каждом нажатии
> клавиши, я очень прошу если есть идеи подскажите как сделать
> такой поиск. Не надо меня переубеждать что нужен другой
> - мне задачу поставили и её необходимо выполнить.
> Заранее сенкс.
>
Тогда в забытом мною фрагменте примера, указанного выше, следует подработать получение значения параметра Ассерt не одним поиском субстроки, а несколькими.
procedure TfrmSubjects.sdqSubjectsFilterRecord(DataSet: TDataSet;
var Accept: Boolean);
begin
inherited;
Accept := pos(FFilterValue, AnsiUpperCase(FField.AsString)) > 0;
end;
Jioniro (2005-09-22 14:51:00) [5]> В целом же не вижу проблемы, т.к. такая накладная формируется
> для каждого магазина не чаще 2-х раз за день. А магазинов,
> как правило, не более 2-х десятков. Нарисовать за раб.день
> 40 накладных, куда, как показывает практика, вставляется
> не более сотни позиций, имхо, не такая уж большая нагрузка
> даже для одного опытного оператора.
в первой версии программного обеспечения так и сделано, но что если магазин только открылся и его наполняют товаром - тогда по 2 тыс наименований в день, или когда приходится догонять магазин - необходимо до пересменка успеть ввести все наименования, да ещё приходы, переброски, переоценки, списания и т.д за эту неделю.
Jioniro (2005-09-22 14:47:00) [6]> загнать таблицу в память, и делать фильтром. уже предлагали,
> быстрее не будет (при передаче в память (клиенстский рекордсет
> к примеру) еще и привести названия к верхшему регистру чтобы
> в фильтре с одной стороны хотябы не делать постоянно).
> энтузиазма предложение не вызвало... вот и предлагают то
> что считают лучшим. а ты нос воротиш.
нет я нос не ворочу!!! я пробую все варианты!!!Спасибо!
Jioniro (2005-09-22 14:45:00) [7]> тогда у него есть свой внутренний код/артикул, иначе он
> сам свой товар с однотипным названием не разберет.
> и этот код/артикул есть на накладной, иначе невозможна отгрузка/поставки/сверки.
> Оператор должен набрать образец:
>
> Метро..400..люкс
>
> и нажать "Поиск"
а если один и тот же товар поставляет в разное время несколько поставщиков, такое бывает постоянно, стои кому-нить из поставщиков снизить цены хоть на 10 копеек.
Мастера - моя задача поставлена и продумана ещё 3 года назад, более того первая версия программного обеспечения написана и юзается, она же и показала недостатки таких методов фильтрации и поиска как по поставшику или при нажатии "Искать".
Как показала 3-х летняя практика необходим поиск по нескольким контекстам именно по наименованию товара и при каждом нажатии клавиши, я очень прошу если есть идеи подскажите как сделать такой поиск. Не надо меня переубеждать что нужен другой - мне задачу поставили и её необходимо выполнить.
Заранее сенкс.
msguns (2005-09-22 14:43:00) [8]Кстати, если речь идет о формировании накладной со склада в розницу (кладовщик или оператор склада/офиса), то очень сильно упрощает и ускоряет набор накладной наличие "Заказа" в этот магазин, в котором просто чекаются соотв.позиции и затем чекнуе скопом переносятся в фактуру, куда проставляется фактически только кол-во и изредка меняется розничная цена.
В целом же не вижу проблемы, т.к. такая накладная формируется для каждого магазина не чаще 2-х раз за день. А магазинов, как правило, не более 2-х десятков. Нарисовать за раб.день 40 накладных, куда, как показывает практика, вставляется не более сотни позиций, имхо, не такая уж большая нагрузка даже для одного опытного оператора.
sniknik (2005-09-22 14:40:00) [9]> я хочу первое, а мне предлагают второе!!!
загнать таблицу в память, и делать фильтром. уже предлагали, быстрее не будет (при передаче в память (клиенстский рекордсет к примеру) еще и привести названия к верхшему регистру чтобы в фильтре с одной стороны хотябы не делать постоянно).
энтузиазма предложение не вызвало... вот и предлагают то что считают лучшим. а ты нос воротиш.
sniknik (2005-09-22 14:35:00) [10]> но что если поставщик поставляет 500 наименований например "Метро"
тогда у него есть свой внутренний код/артикул, иначе он сам свой товар с однотипным названием не разберет.
и этот код/артикул есть на накладной, иначе невозможна отгрузка/поставки/сверки...
в дополнению к фильтру по поставшику этот код будет уникальным значением... не всегда правда ;(, они сами путаются, но в 99,9% случаев, ошибка по нему будет не чаще чем по наименованию.
используй его.
msguns (2005-09-22 14:34:00) [11]>Jioniro (22.09.05 14:27) [23]
>но что если поставщик поставляет 500 наименований например "Метро"
Оператор должен набрать образец:
Метро..400..люкс
и нажать "Поиск"
Это будет много быстрее того, что ты делаешь
Jioniro (2005-09-22 14:27:00) [12]
> сами знаете, что хотите?
я хочу первое, а мне предлагают второе!!!
Jioniro (2005-09-22 14:26:00) [13]
> И попутно вопрос: а зачем накладную на внутреннее перемещение
> вообще вводить - она что, не может передаваться в эл.виде
> и автоматом класться на остатки ?
>
> Если же это приходная (от поставщика) накладная, то для
> поиска лучше использовать дерево товаров или фильтр по поставщику,
> что существенно упрощает поиски.
Накладную на внутреннее перемещение точно также как на приход необходимо заполнить товаром - для этого тоже нужен поиск в каталоге товаров...
Согласен, фильтр по поставщику присутствует, но что если поставщик поставляет 500 наименований например "Метро"
Val (2005-09-22 14:25:00) [14]>[17] Jioniro (22.09.05 14:17)
1:
> как показала практика юзер должен непрерывно видеть результат
> поиска.
2:
> Таким образом юзер вынужден кучу раз тыкать ентер или "Искать"
> и лупиться в монитор в поисках необходимой записи.
сами знаете, что хотите?
Jioniro (2005-09-22 14:23:00) [15]> А нормализовать БД не пробовали?
> Например, делить товары по типам, упаковке, жирности и т.
> п.?
>
> Тогда бы не пришлось выискивать по контексту из названия!
>
нет этого просто нельзя делать, потому что поддерживается импорт других каталогов (например - поставщика) а там типы могут быть другие, по этому запись неделимая но при составлении её выдерживается правило - ВИД. МАРКА, ДОПОЛНЕНИЕ (например: Водка Довгань 0.5 л 40% Дамская Воронеж ЛВЗ)
msguns (2005-09-22 14:22:00) [16]>Jioniro (22.09.05 13:52) [13]
Видимо, речь идет о накладных со склада в магазин..
Тогда см.sniknik © (22.09.05 14:11) [16]
И попутно вопрос: а зачем накладную на внутреннее перемещение вообще вводить - она что, не может передаваться в эл.виде и автоматом класться на остатки ?
Если же это приходная (от поставщика) накладная, то для поиска лучше использовать дерево товаров или фильтр по поставщику, что существенно упрощает поиски.
Курдль (2005-09-22 14:17:00) [17]
> Sergey13 © (22.09.05 13:59) [15]
>
> ИМХО, самое правильное (с интерфейсной точки зрения) и простое
> это отловить в Едите клавишу "Enter" и/или потерю фокуса
> и вызвать при этом обработчик кнопки "Искать".
>
Это чье юзибилити утвердило?
Если прога открывается утром, выключается вечером, а ассортимент товара меняется раз в месяц - тогда и б БД нефиг лазить со своими запросами !
> Jioniro (22.09.05 13:52) [13]
А нормализовать БД не пробовали?
Например, делить товары по типам, упаковке, жирности и т.п.?
Тогда бы не пришлось выискивать по контексту из названия!
Jioniro (2005-09-22 14:17:00) [18]Нет поиск должен быть при каждом нажатии - сокращая кол записей.
При таком описании товара "Масло Долина Сканди 400 гр 80% Легкое Щвеция" как показала практика юзер должен непрерывно видеть результат поиска.
Представь что юзер вводит "Мас" и нажимает ентер помимо всех записей с "масло" будут "маслины", "Масловка" и так далее. Тогда он продолжает ввод и вводит уже "масло" - а этих масел сотни. Таким образом юзер вынужден кучу раз тыкать ентер или "Искать" и лупиться в монитор в поисках необходимой записи.
sniknik (2005-09-22 14:11:00) [19]для накладных самый удобный ввод по баркоду со сканера штрихкодов товара, одно нажатие (просто пронос товара мимо сканера) и никакой путаници. баркоды уникальны (некоторые исключения есть но это именно исключения).
Sergey13 (2005-09-22 13:59:00) [20]ИМХО, самое правильное (с интерфейсной точки зрения) и простое это отловить в Едите клавишу "Enter" и/или потерю фокуса и вызвать при этом обработчик кнопки "Искать".
| |
Страницы: 