Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.07.11;
Скачать: [xml.tar.bz2];

Вниз

Быстрый поиск в БД   Найти похожие ветки 

 
Suharew   (2005-05-15 16:25) [0]

Есть БД Paradox около 1000000 записей. Использую SQL для работы с ней. Когда ищу запись с помошью Locate, он ее находит слишком медленно, ну где-то секунд за 6-7, Подскажите быстрее никак нельзя.


 
Desdechado ©   (2005-05-15 17:47) [1]

Locate к SQL отношения не имеет в принципе.
Делай через SQL маденькие выборки, в которых можно что-то "доискивать" Locate"м. Или же сразу делай выборку так, чтоб условие поиска попадало в WHERE-кусок SQL-запроса.


 
Anatoly Podgoretsky ©   (2005-05-15 20:34) [2]

А больше записей не нашлось?


 
Виталий Панасенко   (2005-05-16 10:33) [3]

Locate uses the fastest possible method to locate matching records. If the search fields in KeyFields are indexed and the index is compatible with the specified search options, Locate uses the index. Otherwise Locate creates a filter for the search.


 
msguns ©   (2005-05-16 11:27) [4]

В любом случае отображаемый НД из миллиона записей - это извращение.


 
Alex_Bredin ©   (2005-05-16 12:08) [5]

Построить индекс и использовать FindKey


 
Sergey13 ©   (2005-05-16 12:15) [6]

2Suharew   (15.05.05 16:25)
> он ее находит слишком медленно, ну где-то секунд за 6-7
Вполне приемлемый результат для лимона записей, ИМХО.


 
Виталий Панасенко   (2005-05-16 15:25) [7]


> Sergey13 ©   (16.05.05 12:15) [6]
> 2Suharew   (15.05.05 16:25)
> > он ее находит слишком медленно, ну где-то секунд за 6-7
> Вполне приемлемый результат для лимона записей, ИМХО.

Не согласен...


 
Anatoly Podgoretsky ©   (2005-05-16 15:35) [8]

Я тоже не согласен, это время нормальное на открытие, но не на поиск. Но время это ерунда по сравнению с травмой психики пользователя.


 
Виталий Панасенко   (2005-05-16 16:07) [9]

Загнал в таблицу из двух полей 1000000 записей - ищет мгновенно по ключу...


 
Sergey13 ©   (2005-05-16 16:14) [10]

2 [9] Виталий Панасенко   (16.05.05 16:07)
А не по ключу?


 
Anatoly Podgoretsky ©   (2005-05-16 16:35) [11]

А не по ключу последовательным перебором


 
Sergey13 ©   (2005-05-16 16:41) [12]

2 [11] Anatoly Podgoretsky ©   (16.05.05 16:35)
Ну и выдет наверное на те-же 6 секунд. 8-)


 
Виталий Панасенко   (2005-05-16 17:06) [13]

Значение в 829473 записи Locate по индексированному (второму) полю - менее секунды, но медленнее FindKey (видно "на глаз")


 
Виталий Панасенко   (2005-05-16 17:13) [14]

Индекс должен быть АКТИВНЫМ по тем полям по которым ищем...В моем тесте, если искать по двум полям, Ф1 и Ф2, но активный индекс для второго поля, поиск около 14 сек !!! если же индекс тот, что нужен - "мухой"


 
Sergey13 ©   (2005-05-16 17:17) [15]

2[14] Виталий Панасенко   (16.05.05 17:13)
Осталось выяснить у автора, что у него за поиск и стОит ли для него делать индексы по всем полям поиска. 8-)


 
suharew   (2005-05-17 23:38) [16]

Спасибо всем за ответы. Ищет все быстро. Оказалось дело в другом.
Посмотрите код

query1.close;
query1.sql.clear;
query1.sql.add("select * from telefon.db order by tel");
query1.open;

query1.locate("tel",trim(t),[loPartialKey]);


Оказывается открывает он долго эту базу с миллионом записей.
Прошу прощения за мой недочет.

Теперь вопрос по другому стоит как базу быстрее открыть?
Возможно ли такое.???


 
sniknik ©   (2005-05-17 23:50) [17]

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

или открыть таблицей (время открытия минимально), а не запросом (смысла в нем? весь выбирается), таблица то у тебя локального типа, не sql сервер.


 
Anatoly Podgoretsky ©   (2005-05-17 23:51) [18]

Зачем тебе миллион записей?


 
Виталий Панасенко   (2005-05-18 09:12) [19]


> query1.close;
> query1.sql.clear;
> query1.sql.add("select * from telefon.db order by tel");
> query1.open;
>
> query1.locate("tel",trim(t),[loPartialKey]);

Ведь выстоящее можно переделать(лучше, конечно, параметр.. лень писать) - будет однохерственно...
query1.close;
query1.sql.clear;
query1.sql.add("select * from telefon.db WHERE TEL LIKE "" + trim(t)+"%"order by tel");
query1.open;


 
Deller   (2005-05-18 11:20) [20]

А что такое trim(t)?


 
suharew   (2005-05-18 12:07) [21]

to sniknik
таблица у меня не совсем локального типа.
ну т.е. программа запускается на одном компе а обращается к базе которая находится на другом компе. поэтому при открытии всей базы дает нагрузку на сеть. попробую открывать таблицей.

to anatoly podgoretsky
у меня база телефонов там находятся и городские номера и сотовые поэтому там их так много. ну ладно не миллион там но около полумиллиона.

Если делать

query1.close;
query1.sql.clear;
query1.sql.add("select * from telefon.db WHERE TEL LIKE "" + trim(t)+"%"order by tel");
query1.open;

то уходит около 5 сек. (т.к. есть сеть)
поэтому как писал ранее анатолий "травмируется психика пользователя".Поэтому пользователь и хочет чуть быстрее чтобы все это работало.


 
Sergey13 ©   (2005-05-18 12:13) [22]

2[21] suharew   (18.05.05 12:07)
>таблица у меня не совсем локального типа.
Локальная, локальная. Только используешь ты ее не по назначению. 8-)


 
Suharew   (2005-05-18 12:56) [23]

to Sergey13
согласен что это не совсем корректно, тем более с базой по сети работают несколько пользователей. Нужно работать с sql сервером, но влом мне.


 
Sergey13 ©   (2005-05-18 13:02) [24]

2[23] Suharew   (18.05.05 12:56)
Если "травмируется психика пользователя", а тебе "влом мне" то наступает непримиримое противоречие, решаемое только административным путем. 8-)


 
Виталий Панасенко   (2005-05-18 14:59) [25]


> Если делать
>
> query1.close;
> query1.sql.clear;
> query1.sql.add("select * from telefon.db WHERE TEL LIKE
> "" + trim(t)+"%"order by tel");
> query1.open;
>
> то уходит около 5 сек. (т.к. есть сеть)

А индекс не пробовал строить по полю TEL ?


 
Sergey13 ©   (2005-05-18 15:11) [26]

2[25] Виталий Панасенко   (18.05.05 14:59)
Подозреваю, что есть индекс. Иначе он не 5 секунд бы ждал наверное на полумиллионе записей. 8-)


 
Виталий Панасенко   (2005-05-18 15:58) [27]


> Подозреваю, что есть индекс. Иначе он не 5 секунд бы ждал
> наверное на полумиллионе записей. 8-)

Проще автору вопроса ответить.. :-) Но провел "эксперимент на себе" - LIKE действительно тормозит... А вот точное сравнение - "мухой".. Это при наличии индекса.. У меня 1000000 записей, добавил еще поле Ф3 символьное, 20.. И положил на сетку, 100 мб


 
suharew   (2005-05-18 23:31) [28]

Да индекс есть. Если база уже открыта по сети то Locate быстро находит. Но т.к. базы открываются SQL запросом то при добавлении информации на одном компе, на другом она не обновляется. Приходится переоткрывать таблицы. Поэтому я при каждом поиске сначала переоткрываю таблицы а потом ищу нужный номер телефона. Поэтому и происходит задержка в 5 сек (пока база откроется, пока номер найдется). Когда база была маленькая около 1000 записей. Вообще все летало.
Впринципе я нашел некоторый выход. Открыть таблицы с помощью Table и работать с таблицей без SQL запросов, т.е. напрямую через TTable. (Edit,insert,post)


 
Sergey13 ©   (2005-05-19 09:18) [29]

2[28] suharew   (18.05.05 23:31)
>Впринципе я нашел некоторый выход.
И что? Открывается быстрее? И/или обновляется автоматом?


 
evvcom ©   (2005-05-19 09:56) [30]

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


 
Anatoly Podgoretsky ©   (2005-05-19 10:02) [31]

evvcom ©   (19.05.05 09:56) [30]
Так то так, но он не совместим, у него лом.


 
evvcom ©   (2005-05-19 10:06) [32]

Действительно, лом и программист в принципе не совместимы. Зато совместимы лом и геморрой!


 
Sergey13 ©   (2005-05-19 10:07) [33]

2[32] evvcom ©   (19.05.05 10:06)
>Действительно, лом и программист в принципе не совместимы.
Это от релиза к релизу меняется. Я бы ен был столь категоричен. 8-)


 
suharew   (2005-05-19 16:43) [34]

2[29] Sergey13
>И что? Открывается быстрее? И/или обновляется автоматом?
При SQL запросе возвращается только результирующий набор данных. Поэтому при добавлении информации, изменений не видно пока не переоткроешь базу, а если использовать TTable тогда база постоянно открыта и обновления вносятся сразу не переоткрывая таблицу т.о. снижается на грузка на сеть.

to Anatoly Podgoretsky
мне не столько влом переделывать все под сервер, просто я как то пытался разобраться с сервером что это и как с ним работать, но так ничего и не получилось. Я же не супер крутой программер. Поэтому подскажите какую-нибудь литературу где все подробненько разжевано про работу с сервером БД. Я даже скачал сервер FireBird, но как говорил раньше ума ему не дал.


 
Sergey13 ©   (2005-05-19 16:49) [35]

2[34] suharew   (19.05.05 16:43)
>При SQL запросе возвращается только результирующий набор данных.
Ты забыл дописать "от SQL сервера". С Парадоксом все несколько иначе.

>а если использовать TTable тогда база постоянно открыта и обновления вносятся сразу не переоткрывая таблицу
Ты забыл дописать "на этом компе". Это справедливо и для Кверика-датасета. Для чужих изменений это монопенисуально - без переоткрытия не увидишь.


 
Санёк   (2005-06-02 09:57) [36]

А Ты не пробовал положить табличку с миллионом записей на какой-нибудь компьютер в локальной сети?
Особенно при первом открытии (пока не скеширована табличка), засеки время: 6-8 секунд может не хватить.
Иногда встречаются заказчики с 10-Мбитной сетью.


 
Виталий Панасенко   (2005-06-02 10:29) [37]


> >а если использовать TTable тогда база постоянно открыта
> и обновления вносятся сразу не переоткрывая таблицу
> Ты забыл дописать "на этом компе". Это справедливо и для
> Кверика-датасета. Для чужих изменений это монопенисуально
> - без переоткрытия не увидишь.

А зачем тогда Refresh ?


 
Sergey13 ©   (2005-06-02 10:41) [38]

2[37] Виталий Панасенко   (02.06.05 10:29)
А при чем тут Refresh ? Что ты собираешься решрешить?



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2005.07.11;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.54 MB
Время: 0.035 c
14-1117815608
Андрей Жук
2005-06-03 20:20
2005.07.11
О геноциде


1-1118440251
KOLIG
2005-06-11 01:50
2005.07.11
Упаковка файлов


1-1118397912
Dysan
2005-06-10 14:05
2005.07.11
помогите понять в чем причина возникновения ошибки!


14-1118735941
leonidus
2005-06-14 11:59
2005.07.11
Отзовитель кто пишет плагины для FireFox


3-1116159931
Suharew
2005-05-15 16:25
2005.07.11
Быстрый поиск в БД





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский