поиск

← →
Spectrum © (2007-07-14 18:47) [0]

Привет всем. Оч. нужно! Есть такая проблема: необходимо реализовать поиск по двум полям в одной таблице PX( по ФИО и дате рождения), причем поиск должен осуществляться путем нажатия на 1 кнопку, а поле "ФИО" при поиске необходимо привести в единому регистру, во избежание ошибки при вводе. Заранее благодарен!

← →
sniknik © (2007-07-14 19:03) [1]

нужно реализовывай! зачем тебе наше разрешение? а если не дадим?

← →
Spectrum © (2007-07-14 19:21) [2]

зачем так? если можешь помоги!

← →
Anatoly Podgoretsky © (2007-07-14 19:28) [3]

> Spectrum (14.07.2007 18:47:00) [0]

Смотри Locate, но из-за требования регистра тебе придется делать через Next

← →
Anatoly Podgoretsky © (2007-07-14 19:31) [4]

Хотя смотри на третий параметр функции Locate, но из-за ошибок с локализацией в драйверах БДЕ это может давать сбои для букв "Я" и "ч"
В Д10 это вроде наконец исправили, не уверен, поскольку в данное время не использую БДЕ.

← →
MsGuns © (2007-07-14 21:56) [5]

Select * from Table
where <хоть по 1 полю, хоть по 10-ти, хоть с учетом регистра, хоть без>

← →
VadimSpb (2007-07-14 23:07) [6]

Смотри Locate, но из-за требования регистра тебе придется делать через Next
Уважаю. Поражен. Зачем Locate? Очень долго.

> Select * from Table
> where

Очень быстро и т.д.

← →
sniknik © (2007-07-15 00:05) [7]

> Очень долго.
> ...
> Очень быстро и т.д.
уверен, проверим?

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

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

p.s. не все так просто, даже на реальной, а не искуственной проверочной таблице (которая только для "очевидности"), чтобы так однозначно говорить, что одно плохо(/медленно) другое хорошо(/быстро).
и потом пусть нашел ты селектом всего одну запись, дальше то что? выборка это еше не поиск... нужно то найти, судя по всему, т.е. в отображаемой клиенту таблице установить курсор на нужную запись.

← →
Anatoly Podgoretsky © (2007-07-15 00:29) [8]

> MsGuns (14.07.2007 21:56:05) [5]

Это не поиск, а "фильтр", поиск это перемещение на запись.

← →
VadimSpb (2007-07-15 01:14) [9]

> уверен, проверим?

Да. Проверял на своей шкуре и на MS SQL 2005. Клиенты достали при выборке нужной записи. Запросом все пошло значительно быстрее. Даже таймера для проверки не пришлось ставить.

> нужно то найти, судя по всему, т.е. в отображаемой клиенту
> таблице установить курсор на нужную запись.

Не факт. Зачастую и не надо. Для этого еще есть Lookup.

> поиск это перемещение на запись.

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

← →
Германн © (2007-07-15 02:48) [10]

> Anatoly Podgoretsky © (14.07.07 19:31) [4]
>
> Хотя смотри на третий параметр функции Locate, но из-за
> ошибок с локализацией в драйверах БДЕ это может давать сбои
> для букв "Я" и "ч"
> В Д10 это вроде наконец исправили, не уверен, поскольку
> в данное время не использую БДЕ.
>

Вообще это очень тёмное дело что, когда и как исправили. Мне удалось получить правильную работу с этими буквами. Но вот в результате чего именно, я так и не понял (при детальном анализе).
Но после тех экспериментов у меня DBD в системе, где установлены Д4 и Д6 по завершении работы выдаёт "Unexpected General Protection Violation". И никак я его побороть не смог :(((

← →
sniknik © (2007-07-15 10:01) [11]

> Да. Проверял на своей шкуре и на MS SQL 2005.
вот как знал когда про тип базы дописывал... говорил же для заданного в вопросе типа базы. ты вообще разницу между клиент сервером и файл сервером знаеш?

> Это определение? Тогда не согласен, тоже не факт.
это здравый смысл. к чему привык пользователь (да и все мы) нажимающий "искать" в ворде или в блокноте? к тому что получит выборку из 10 строк с встречаемым в них искомым словом?
нет, и потому поик <> выборке.

> А если необходимо осуществить ПОИСК 10 записей?
их надо находить последовательно.

> Вообще, фраза "поиск" тянется от литературы по BDE. В описании SQL используют: фильтрация, выборка, извлечение данных.
ну вот видиш. читал значит что это разные вещи, а выводов не сделал. путаешь одно с другим.

← →
VadimSpb (2007-07-15 11:07) [12]

> вот как знал когда про тип базы дописывал

Согласен, возможно. В BDE не проверял.

> это здравый смысл

Здравый смысл - понятие житейское, обывательское, ets. Весьма субъективное. И у каждого он свой ;-))

> к чему привык пользователь (да и все мы)

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

> нет, и потому поик <> выборке

Молодец! Подсознательно понимаешь.

> > А если необходимо осуществить ПОИСК 10 записей?
> их надо находить последовательно.

Это что - Указ Президента? Понятно, что физически процесс будет идти последовательно вне нашего желания - надо или не надо. Весь вопрос в представлении данных. Что, и выводить надо последовательно? Ясно - нет, как хотим, так и выводим.

> ну вот видиш. читал значит что это разные вещи, а выводов
> не сделал. путаешь одно с другим.

Вот и пытаюсь это тебе показать :-)))
Повторюсь, прочти внимательно:
Полагаю, поиск записи(ей) - это более расширенная категория, которая может решаться различными способами (методами), напр. фильтрацией.
Насколько я понимаю твою логику, ты считаешь поиском только ту процедуру, когда курсор устанавливается на нужную запись. Поясни если не так.
ИМХО, это просто узкое толкование. А если используем Lookup? Курсор на месте, а запись нашли!

← →
MsGuns © (2007-07-15 12:08) [13]

>Anatoly Podgoretsky © (15.07.07 00:29) [8]
>Это не поиск, а "фильтр", поиск это перемещение на запись.

Почему ? Ведь результаты запроса не отображются в сетке, а "лежат" в отдельном датасете, откуда вытаскивается очередная запись (следующая, предыдущая, первая и т.д.) и по UID ищется тем же Locate в основном (отображенном в гриде) НД

← →
sniknik © (2007-07-15 15:56) [14]

VadimSpb (15.07.07 11:07) [12]
> Полагаю, поиск записи(ей) - это более расширенная категория, которая может решаться различными способами (методами), напр. фильтрацией.
нет, поиск это поиск, фильтрация - фильтрация, и т.д. называя вещи своими именами избегаешь многих проблем. а вы получатся говорите одно, подразумеваете другое, а делаете третье (типа "а фигня, все равно это одно и тоже в "расширенной категории"").

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

> А если используем Lookup? Курсор на месте, а запись нашли!
не нашли, а выбрали из локального рекордсета. это ближе к селекту, только на локали.

MsGuns © (15.07.07 12:08) [13]
> и по UID ищется тем же Locate в основном (отображенном в гриде) НД
в [7] это было. и пример, в котором выборка займет минуты, а поиск (Locate) что по UID что по условию миллисекунды, с небольшой разницей.

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

← →
VadimSpb (2007-07-15 16:25) [15]

> называя вещи своими именами избегаешь многих проблем

Полностью согласен. Потому и пишу сейчас.

> поиск это поиск, фильтрация - фильтрация

Забавное определение :-)) А конкретнее можно?

> любой способ которым найдет нужную запись/слово, непосредственно
> в записях/тексте

А что, фильтрацией мы не находим нужную запись (данные)?

> а вы получатся говорите одно, подразумеваете другое, а делаете
> третье (типа "а фигня, все равно это одно и тоже в "расширенной
> категории"").

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

Может обратиться к словарю?
Lookup - поиск, синоним find.
Locate - определить местонахождение.
И скорее получается, следуя логике разработчиков BDE, что при Lookup мы осуществляем поиск, а не наоборот.

Пожалуйста, дайте свое четкое определение поиску и чем он отличается от фильтрации.

← →
RayGun © (2007-07-15 16:48) [16]

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

← →
VadimSpb (2007-07-15 16:51) [17]

Прежде всего надо предложить автору не использовать BDE. Если это возможно в контексте его задачи.

> VadimSpb (15.07.07 16:51) [17]
> Прежде всего надо предложить автору не использовать BDE. Если это возможно > в контексте его задачи.

Почему же? Если он использует локальную БД, то BDE - вполне нормальный вариант. Хотя есть варианты и по-лучше.

← →
VadimSpb (2007-07-15 16:57) [19]

> BDE - вполне нормальный вариант

Уже нет. Тупиковый.

> Хотя есть варианты и по-лучше

Поэтому и надо предложить.

Весьма вероятно, что это учебное задание. Если так, то ничего не поделаешь, если нет - то можно выбирать: AbsoluteDB, Firebird Embedded, eXtremeDB, а то может и просто ClientDataSet, TMemData и т.п.

← →
VadimSpb (2007-07-15 17:16) [21]

Я бы использовал TNotСlever и TFool.

Автора что-то не видно, видимо, усиленно гуглит на тему TNotClever и TFool.

Да ребята, неожидал таких дискуссий! Впринципе через Lokate все прокатило. Пасиба всем

> > BDE - вполне нормальный вариант
>
> Уже нет. Тупиковый.

Но тем не менее, работает. И вполне себе нормально.

поиск Найти похожие ветки