Запись в таблицу и поиск

← →
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) и много чего узнаете. Например то, что в некоторых случаях создание "лишних" индексов может существенно ЗАМЕДЛИТЬ поиск и (особенно !) выборку.

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

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

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

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

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

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

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

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

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

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

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

Чтобы дальше не спорить привожу результаты своего теста
Тест проводился на 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

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