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

Вниз

Запись в таблицу и поиск   Найти похожие ветки 

 
MixAnOL ©   (2006-10-04 16:21) [0]

Здарова Всем!

Возник вопрос, мне нужно организовать поиск среди нескольких десятков тысяч текстовых строк. Т.е. выбрать строки соответствующие, например, шаблону "йц*". Причем набор строк строится  динимически.
Вот и думаю как это сделать, что бы поиск занимал минимальное кол-во времени.
Подумал, что можно загонять в таблицу и SQL LIKE мне там поможет... и соответственно возник вопрос какую СУБД использовать.

Где-то видел, но не смог сейчас найти, компоненты поддерживающие SQL для простых таблиц...


 
Desdechado ©   (2006-10-04 16:24) [1]

Если тебе только по первым символам искать, то никакой SQL и СУБД 100 леи не нужен. Просто сортируешь свой TStringList и потом в сортированном это ищется моментально. Можешь свой двоичный или другой поиск подключить.

Кстати, если не по первым символам искать, то LIKE в SQL не будет использовать индекс, т.е. все равно толку нет.


 
Stanislav ©   (2006-10-04 16:25) [2]

MSACCESS подойдет, если одновременно будет работать 1 пользователь.
А на текстовое поле нужно поставить индекс.


 
MixAnOL ©   (2006-10-04 16:41) [3]


> MSACCESS подойдет, если одновременно будет работать 1 пользователь.
>
> А на текстовое поле нужно поставить индекс.

А тормозить не будет, если я туда 80000 строк текста[255] закорячу?

> если не по первым символам искать

нужно не только по первым...


 
Stanislav ©   (2006-10-04 16:44) [4]

MixAnOL ©   (04.10.06 16:41) [3]
недолжно.


 
MixAnOL ©   (2006-10-04 16:51) [5]

там в акцесе вроде фишка была, что при delete from table1, сами записи не удаляются, т.е. если я 100 раз засуну в таблицу по 80000 строк, то у меня база нехилая станет по размеру..


 
Sergey13 ©   (2006-10-04 16:55) [6]

> [3] MixAnOL ©   (04.10.06 16:41)

А откуда эти 80000 строк?


 
AngeL B.   (2006-10-04 16:58) [7]


> нужно не только по первым...

А тогда всё равно что использовать, потому что поиск всё равно будет линейным.

Можно и просто TStringList вместе с for-ом и pos-ом


 
sniknik ©   (2006-10-04 17:04) [8]

> там в акцесе вроде фишка была, что при delete from table1, сами записи не удаляются
эта фишка практически в любой базе... (так сразу и не вспомнить где этого нет...)

> т.е. если я 100 раз засуну в таблицу по 80000 строк, то у меня база нехилая станет по размеру..
> 80000 строк текста[255] с текстом "под завязку" до последнего байта, это примерно 40мег. 100 ра это 400 мег., пока до 1,5 гигбайта не дойдет можеш не буспокоиться, а место из под удаленных записей используется повторно...

> Можно и просто TStringList вместе с for-ом и pos-ом
движок базы скорее всего сделает это более оптимальным способом. сравнить бы надо.


 
MsGuns ©   (2006-10-04 17:10) [9]

>Stanislav ©   (04.10.06 16:25) [2]
>MSACCESS подойдет, если одновременно будет работать 1 пользователь.

Глупость

>А на текстовое поле нужно поставить индекс.

Еще одна.


 
MixAnOL ©   (2006-10-04 17:10) [10]


> движок базы скорее всего сделает это более оптимальным способом

вот почему мне и не охота руками поиск делать...


 
Stanislav ©   (2006-10-04 17:12) [11]

MsGuns ©   (04.10.06 17:10) [9]
?


 
sniknik ©   (2006-10-04 17:20) [12]

> MsGuns ©   (04.10.06 17:10) [9]
> ?
поиск внутри строки индексов не использует, а к базе аксесса разрешено до 5ти подключений с одной машины (вернее там сформулировано более хитро, типа "гарантируется работа" или типа того, не хочу смотреть в доку лень, а на самом деле позволяется гораздо больше)


 
Stanislav ©   (2006-10-04 17:27) [13]

sniknik ©   (04.10.06 17:20) [12]

Для многопользовательской работы может подойти больше другая БД.
А индекс используется при Like "йц*". , не используется в Like "*йц*", во всяком случае в MSSQL.


 
MsGuns ©   (2006-10-04 17:33) [14]

>Stanislav ©   (04.10.06 17:27) [13]
>Для многопользовательской работы может подойти больше другая БД.

Для организации многопользовательской работы нужна прежде всего другая ТЕХНОЛОГИЯ. А уже потом "другая БД".

>А индекс используется при Like "йц*". , не используется в Like "*йц*", во всяком случае в MSSQL.

Поинтересуйтесь механизмом использования индексов "серверными поисковиками" (например, в том же BOL для MS SQL) и много чего узнаете. Например то, что в некоторых случаях создание "лишних" индексов может существенно ЗАМЕДЛИТЬ поиск и (особенно !) выборку.


 
sniknik ©   (2006-10-04 17:45) [15]

> Для многопользовательской работы может подойти больше другая БД.
это вовсе не одно и тоже с "аксесс может работать только с одним пользователем".

> А индекс используется при Like "йц*". , не используется в Like "*йц*", во всяком случае в MSSQL.
под фразу в [12] "внутри строки" подходит только второй вариант, т.к. первый это будет вначале. т.е. ты повторил сказаное в [12] только своими словами... не пойму, повторение является ответом? или есть какойто другой, тайный смысл послания?


 
Stanislav ©   (2006-10-05 08:44) [16]

1. На момент моего ответа [2]. речь нешлп о поиске внутри строки, поэтому индекс был просто необходим.
2. Даже при поиске либо внутри строки либо по первым буквам индекс такж е необходим, т.к. при поиске внутри строки он просто использоваться не будет, а при поиске по первым буквам скорость поиска увеличиться в разы.
К тому же автору захочется отсортировать найденый материал, где индекс также необходим.
3. MsGuns ©   (04.10.06 17:33) [14]  Я отлично знаком с индексами и могу уверить что это не тот случай где индекс может мешать выборке.
4. А для развеевания сомнений MsGuns ©  мы попросим MixAnOL © произвести тест на производительность с индексом и без и опубликовать результаты, если конечно MixAnOL © не против.
со sniknik © по поводу Access спорить не буду, но обращаю внимание что я не говорил что акцесс может работать с одним пользователем
MSACCESS подойдет, если одновременно будет работать 1 пользователь - это несет совершенно другой смысл.
Исходя из вышесказанного можно с полной уверенностью заявить что глупости были высказаны в [9] , [14].
А в [2] ответы на вопросы изложенные в автором.
ВОТ!


 
Sergey13 ©   (2006-10-05 09:02) [17]

> Причем набор строк строится  динимически.

Если это происходит перед каждым поиском, то использование БД, ИМХО, вообще нецелесообразно.


 
MsGuns ©   (2006-10-05 10:18) [18]

>Stanislav ©   (05.10.06 08:44) [16]
>Исходя из вышесказанного можно с полной уверенностью заявить что глупости были высказаны в [9] , [14].

Блажен кто верует ;)

>А в [2] ответы на вопросы изложенные в автором.

А в [2] есть ответы на поставленные вопросы ?


 
MixAnOL ©   (2006-10-05 11:58) [19]


> мы попросим MixAnOL © произвести тест на производительность
> с индексом и без и опубликовать результаты, если конечно
> MixAnOL © не против

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


 
Stanislav ©   (2006-10-05 15:10) [20]

Чтобы дальше не спорить привожу результаты своего теста
Тест проводился на ACCESS c таблицей в 316945 записей,
Размер текстового поля - 100 знаков
Максимальная длинна внесенной строки состовляет 35 знаков
Запрос:SELECT Count(*) AS CNT
FROM dbo_SOSTDET
WHERE (((dbo_SOSTDET.NOMDOK) Like "%37%"));
Вот результаты
параметр-колво записей - время в сек без инд. - время в сек с индексом
%37 - 854 - 0,045 - 0,045
37 - 39 - 0,06 - 0,04
37% - 1425 - 0,044 - 0,0006
%37%-3504-0,045-0,045



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

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

Наверх




Память: 0.5 MB
Время: 0.055 c
2-1163940953
zenov
2006-11-19 15:55
2006.12.10
Как организовать список директорий в LISTBOX?


2-1164374487
dimass
2006-11-24 16:21
2006.12.10
Проблема VCL.Net


2-1164247598
uleess
2006-11-23 05:06
2006.12.10
Необходим дозвоньшик в интернет уневерсальный! Для Win98 и WinXP


15-1163861579
vasIzmax
2006-11-18 17:52
2006.12.10
Алгоритм, Футбол, Тотализатор


1-1162187327
Николай1984
2006-10-30 08:48
2006.12.10
Бинарные деревья (деревья поиска)





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский