Слаба богу. Можете меня поздравить. Наконец то я понял что к чему.
Видимо, настолько идиотская постановка задачи была, извиняюсь
Да, в данном конкретном случае работать будет, а что, если у меня есть скажем, регулярное выражение ^[12][0123456789]{4}$ или что то вроде ^[pр]ri[vw][eе]t |^привет |^здрав |^zdr[aа]v.... как тут быть?..
Тут уже точно не написать функцию которая может преобразовать входную строку в нужную регулярку...
P.S. "T.REG" обозначалось поле таблицы T, хранящее шаблоны-рег. выражения
EuGen
Бот выдает ошибки, где можно прочитать подробную настройку?
Документация лежит на том же сайте, откуда бота качал. А вообще - у бота этот писан каким-то челом, который наверняка присутствует в описании проги. Вот у него и спроси если еще останутся вопросы после прочтения документации.
Я сам этого бота не юзал.
Да я тоже так думал, но оказалось, что нельзя изменять уже существующие шаблоны.
Да и, если честно, я не очень понял как это поможет по вводу скажем st показывать поисковиком пресловутое выражение для "стан" ...
В первом случае интерпретатор будет вынужден сделать вызов list но зато во втором выбираются все поля из таблицы без каких-либо условий! Это значит, что если таблица скажем пару миллионов строк и содержит один-два атрибута типа text или blob, такой код сильно увеличит нагрузку на сервер БД.
Так что с этой точки зрения, конечно же, 1-й вариант предпочтительнее.
Для поиска в полне подойду регулярки, а для второго придётся использовать чтото другое.
Наверное, это "что то" и предстоит построить.
Я правильно понял, Вы предлагаете поисковику делать так: REGEXP не по T.REG а по f(T.REG), где f - возвращает T.REG с отрезанными ^ и $ (если таковые имеются на концах),
А обработчику - по оригинальному значению T.REG ... ?
Что же, пробую еще раз, менее отвлекаясь уже на описание среды где это используется (потому что в первом описании, по моему, о ней уже все сказано)
Итак, предположим у нас в таблице базы (обзову ее тогда "T") есть записи с некоторыми регулярным выражениями (обзовем поле, в котором хранятся наши регулярки, как T.REG)
Пользователь желает узнать, можно ли в базу добавлять строку S0. Для этого он делает запрос к скрипту-поисковику. Тот, в свою очередь, делает запрос SELECT * FROM T WHERE S0 REGEXP T.REG
И по логике получает, что, если S0 не подпадает ни под одно имеющееся в T.REG выражение, то S0 можно добавить в T, где S0 уже будет считаться регулярным выражением.
Далее, скрипт обработчик должен по входной строке S1 найти единственную запись в T, которой соответствует S1. Делает он это так: SELECT * FROM T WHERE S1 REGEXP T.REG
Соответственно, он находит запись в T, поле T.REG которой есть регулярное выражение, под которое подпадает S1.
А теперь представим себе такую ситуацию:
-на момент добавления S0 в T существовала запись, T.REG которой соответствует некоторой строке S2, причем S0 есть подстрока S2.
-Обработчик начнет искать в T указанным запросом строку S2. Тогда, так как S2 REGEXP (T.REG, соответствующее S2) есть истина, и S2 REGEXP S0 есть истина, мы получим не 1, а 2 записи, то есть крах системы.
Собственно, задача состоит в том, чтобы такого не допустить и как то обрабатывать описанные ситуации, причем делать это по логике надо еще на стадии поисковика, то есть не давать юзеру вводить S0, если есть T.REG такое, что для него существует S2 и S0 есть подстрока S2.
Вообще говоря, мне кажется, что случай с подстроками не единственный возможный случай коллизии.
Наверное, нужно было еще подробнее расписывать, но я не придумал как это лучше изложить, прошу прощения.
Предложенное решение спасает только на случай приведенного примера, но регулярное выражение, вообще говоря, может быть произвольным и тогда либо становится невозможным написание функции, которая из строки делает ее регулярное выражение, так как входной строке могут соответствовать несколько регулярных выражений (в общем случае бесконечное множество)
Создавая эту тему, я не предполагал, если честно, что мне будет предложено хоть что то, так как задача и вправду нетривиальная, так что все хорошо - спасибо, как говорится, и на том!
Спасибо, но проблема тут в том, что как мне решить, когда поисковику искать через LIKE, а когда - через REGEXP .. (сейчас все шаблоны считаются регулярными выражениями, то есть поиск всегда через REGEXP идет).
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 8901
