Как сделать поиск по регулярному выражению SQL?

Question

[generate]

SELECT * FROM `post` WHERE `description` REGEXP 'itemid=34543[^\d]*'

Хочу найти такое значение itemid=34543 после этого всё что угодно кроме цифр но почему то выдает не то, подскажите как правильно использовать все кроме в sql

Comments

[Евгений]

Там вроде \d \w не работают, [:digit:] используйте

[generate]

Евгений,
itemid=34543[^[:digit:]]*
так чтоли ?

[Евгений]

generate, да)

[generate]

Евгений, Вообще не так ищет он так все записи выбирает не смотрит на числа

[Евгений]

generate, покажи пример строки, которую парсим

[generate]

"success=ok||type|пост||name|Вася||itemid=34543"
такая строка, itemid=34543 может быть вначале в конце или посередине рандомно вообщем

[Антон Соломонов]

itemid=34543([\D]|$)

[generate]

Антон Соломонов, такая же проблема очень много результатов

[Антон Соломонов]

generate, какие результаты попали в выборку, которых не должно быть?

[generate]

Антон Соломонов, все что есть попали %LIKE% ищет норм но если я ищу 1, то попадуться все у кого есть цифры 1 в начале
а так itemid=34543([\D]|$) он берет почти все без разбору кого есть itemid название

[Антон Соломонов]

Под рукой был только postgresql, поэтому вот вариант который работает на нем.

В таблице:

success=ok||type|пост||name|Вася||itemid=34543
success=ok||type|пост||name|Вася||itemid=3454312312
success=ok||type|пост||name|Вася||itemid=34543asld
itemid=34543||success=ok||type|пост||name|Вася
itemid=34543123||success=ok||type|пост||name|Вася

Запрос:

SELECT val from tmp where val ~ 'itemid=34543([^[:digit:]]|$)';

Результат:

success=ok||type|пост||name|Вася||itemid=34543
success=ok||type|пост||name|Вася||itemid=34543asld
itemid=34543||success=ok||type|пост||name|Вася

Answer 1

[Мирон]

У Вас есть 2 основных подхода
1. через 2 выражения пользуясь операторами перечисленными здесь
https://dev.mysql.com/doc/refman/8.0/en/regexp.html
Возможно не всеми в любой комбинации, но существенно то, что один оператор должен найти часть последовательности символов, которые должны ответить, например
SELECT *
FROM `post`
WHERE
-- 1-е выражение
`description` LIKE 'itemid=34543%'
-- 2-е выражение
AND
`description` NOT RLIKE 'itemid=34543[0-9]+'

2. через 1 регулярное выражение, очень похожее на то, которое Вы предложили, но видимо с \ ( backslash ) символом проведенным дважды, на той же странице объясняется почему: "Because MySQL uses the C escape syntax in strings (for example, \n to represent the newline character), you must double any \ that you use in your expr and pat arguments."
Если по той или иной причине выражение артачится, наверное можно воспользоваться выражением на один символ длиннее, для выражения цифр [^0-9]
Ну и наверное надо воспользоваться плюсом, а не звездочкой справа [^0-9]+, иначе эта часть становится не обязательной, и запрос может выбрать, например, значение 'itemid=34543'
---
Всего хорошего!

Answer 2

[ThunderCat]

TL;DR: переписывайте базу пока не поздно. Приводите в 3 нормальную форму и будет вам "щастие".

1) Хранение данных по которым идет поиск в таком виде - это сразу расписаться в своей проф. непригодности, никому не показывайте эту стыдобу.

2) Разнесите данные нормально по таблицам, не думайте что вы прям "выкрутились" захерачив все в строку и у вас все в шоколаде. Нифига, теперь у вас по этому полю будут кошмарно тормозные запросы, так как самые медленные операции - это лайк и регексп. Тем более по полю с переменной длинной и без нормальных индексов. И все это вместо суперскоростного индекса по интежер полю.

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

4) ну и на одну из проблем вы уже напоролись - поиск по нечетким данным даст нечеткий результат.

Comments

[generate]

это cms такая доп поля так написаны

[ThunderCat]

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

[generate]

ThunderCat, Эта удобно если считать что доп полей может быть 20-50 штук. больше 10 колонок в базе создавать это как то не очень )

[ThunderCat]

generate,

Эта удобно если считать что доп полей может быть 20-50 штук.

вообще для этого есть специальный паттерн хранения - EAV. Никаких 50 полей в базе не нужно.

[Антон Соломонов]

Все же человек спросил о другом. Он поинтересовался как сделать запрос, а не как сделать архитектуру БД оптимально. Более того, автор не расписал контекст задачи, однако вы уже у себя в голове все продумали и решили упрекнуть автора в некомпетентности.
- Почему вы решили что автор является архитектором БД?
- Почему вы решили что этот запрос будет выполняться постоянно, а не к примеру разово?
- Почему вы решили что ему нужно читать/парсить/менять?

Будьте сдержаннее в выводах. Если закрались сомнения - поинтересуйтесь. ;-)

[ThunderCat]

Антон Соломонов,

Он поинтересовался как сделать запрос, а не как сделать архитектуру БД оптимально.

Не суть важно кто написал, факт остается фактом - есть бд с кривой структурой, это надо исправлять.

Почему вы решили что автор является архитектором БД?

Если ТС не ее проектировщик, то и принимать на свой счет какую-либо критику он не будет. А вот переделать как надо - задача нормального разработчика.

Почему вы решили что этот запрос будет выполняться постоянно, а не к примеру разово?

Во первых - почему нет? Во вторых - исходя из опыта и структуры предоставленных данных, явно это связь с каким-то объектом, описанным вот таким кривоватым способом, по которому идет поиск.

Почему вы решили что ему нужно читать/парсить/менять?

Я вообще ничего не решал, просто указал на проблему такого типа хранения. Вы вообще читаете что написано, или просто пофлеймить зашли?

Будьте сдержаннее в выводах.

Давайте без вот этого вот, "политкорректность, блм, точки в конце предложения это агрессия" и прочий шлак? Мои выводы если где-то не точны, их поправит автор вопроса. А если ему интересно как сделать правильно и ему хватит опыта и компетенции понять что надо сделать и реализовать это - будет вообще замечательно.

[Василий Банников]

generate, можно же json в базе хранить. Не знаю, что тут за СУБД, но постгрес вроде умеет даже индексы по json-полям строить.

UPD: пардон, не увидел, что тут mysql

[ThunderCat]

Василий Банников, Мускуль тоже умеет, но вообще хранение данных в жсоне норм только если это не поисковые данные. Да, на них создаются вполне адекватные индекксы, но работа с этими данными все равно не то же самое что отдельная таблица, есть как проблемы с джоинами, так и с индексированием, если сам жсон не единообразный, как в данном случае.