Нечеткий поиск в БД

[Andrey Fedorov]

Вопрос тупиковый adUseClient

Ведь знаешь

Ну и при чем тут тогда скорость по сетке - один раз данные таблички прочитать?

[MOV]

Cn.CursorLocation = adUseClient
CursorLocation - как понимаю, указатель текущей записи, ну тот, что как бы самому провайдеру принадлежит (короче курсор) либо юзать клиентский, либо сервака.
Просто никогда не смотрел на опыте разницу - это было всего лишь предположение.
Значит, говоришь клиентский курсор быстрее. Ок.

[MOV]

Короче вот так вот! Блин!

[Andrey Fedorov]

Короче вот так вот! Блин!

Ищет-то не так как надо, например:

Введено для поиска: Chug
Должны найтись: Chai, Chang

А у тебя вообще ничего не найдется...

[MOV]

Вообще, жаль что не видно автора - не у кого спросить

Но даже, если и так, это поправить легко. Я говорю про саму методу: зачем писать функции, если SQL для поиска с головой хватает и скорость гораздо выше, чем у самодельных функций на VB?

Ну где же он?! Некому рассудить нас. .

Поэтому признаю, что твой поиск неплох и даже очень хорош, но медленно работатет. Поэтому надо думать что-то с SQL

[alibek]

Не поможет тут SQL, у него вполне определенные задачи и область применения. А эта задача выходит за его рамки, надо использовать пользовательскую функцию. Ее можно использовать в своей проге (клиентский курсор), либо на сервере, в таком случае сервер должен быть (например) MS SQL.

[Andrey Fedorov]

Вообще, жаль что не видно автора - не у кого спросить

Пропал куда-то...

Я говорю про саму методу: зачем писать функции, если SQL для поиска с головой хватает и скорость гораздо выше, чем у самодельных функций на VB?

В Access-e подобную функцию не написать. Можно написать на SQL-сервере, но быстрей она от этого не будет - чудес не бывает.

Сомневаюсь что сильно быстрей будут и аналогичные средства самого SQL. Точнее они могут быть быстрей только за счет более удачного алгоритма и более быстрой и незагруженной машины сервера, но тут уже надо смотреть.

Ну и в конце-концов Автор хотел быстрее 30 секунд - дык условие выполнено - получили около 3 секунд.

[MOV]

В Access-e подобную функцию не написать.

Не догоняю. Почему?
(Я плохо представляю, что нельзя сделать в Access такого, что можно сделать в SQL-сервер по скольку все-таки больше работаю с Accessom ).
Будет время - попробую перебросить твою функцию туда.
Но если сразу образумишь, чтобы время не терял буду благодарен.

[Andrey Fedorov]

Имеется в виду что в Access-e ты не сможешь написать запрос реализующий то что делает эта функция. Без использования функции в модуле.

[MOV]

Я это понимаю, что одними запросами здесь трудновато отделаться.
Ладно, оставим эту тему.
А общих чертах, ты можешь сказать чем SQL-сервер лучше Accessa?
Я как-то ставил у себя SQL-сервер, на мой взгляд он медленно работает, чем access, среда написания запросов какая-то неудобная, (ну или непривычная после Access).
Хотя интерфейс в чем-то более серьезный .
В чем приемущество хранимых процедур, как понимаю - это аналогия VB-кода в модуле accessa только они сделаны на T-SQL? так?
Может БД на SQL-сервере, может деражть больше пользователей? Хотя я толком не знаю сколько максимум пользователей можно повестить на одну mdb-ху на серваке.
Да, в SQL-сервере более удобно организовано создание политик для пользователей, управление доступом... (в access я этим не пользовался, поэтому не знаю на сколько это удобно там, максимум запаролить базу могу , а дальше вроде не было необходимости).
И вообще в организациях в основном SQL-сервер стоит .

[Andrey Fedorov]

А общих чертах, ты можешь сказать чем SQL-сервер лучше Accessa?

Хм. Надежность, обработка заданий непосредственно на сервере, на порядок больше возможностей...

Я как-то ставил у себя SQL-сервер, на мой взгляд он медленно работает, чем access, среда написания запросов какая-то неудобная, (ну или непривычная после Access).

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

В чем приемущество хранимых процедур, как понимаю - это аналогия VB-кода в модуле accessa только они сделаны на T-SQL?

В том что они выполняются на самом сервере - по сети трафик меньше.

Может БД на SQL-сервере, может деражть больше пользователей?

Да.

Да, в SQL-сервере более удобно организовано создание политик для пользователей, управление доступом... (в access я этим не пользовался, поэтому не знаю на сколько это удобно там, максимум запаролить базу могу , а дальше вроде не было необходимости).

В Access-e тоже неплохое разграничение доступа.

[MOV]

Спасибо. Ухожу в отпуск - надо будет внедриться получше в SQL-сервер.

[alibek]

Вдогонку скажу, что Access не является полноценной СУБД. Он удобен для "настольного" пользования, но для системы "клиент-сервер" у него слишком много ограничений.

[Cyrax]

а кто-нибудь вспомнил про Regular Expresion?
идея такова:
открываем Recordset -> забираем все записи в массив (естественно, нам нужны только поле по которому мы ищем и ключевое поле) -> пробегаемся по массиву, подставляя каждый элемент в качестве объекта надругательств для RegExp (тут самое главное - правильно составить это самое регулярное выражение) -> в зависимости от того, что мы получили в результате применения RegExp помечаем подходящие элементы массива -> если больше нам ничего не нужно, то показываем то, что нашли, либо подставляем ключевые поля отобраных елементов в SQL-запрос (если нужны дополнительные поля из таблицы)

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

[alibek]

Этот вариант предлагали в самом начале.
Копья стали ломать из-за того, что хотели получить серверный курсор с отобранными записями.

[Cyrax]

Этот вариант предлагали в самом начале.
Копья стали ломать из-за того, что хотели получить серверный курсор с отобранными записями.

тогда "ОЙ!"