UPDATE + регулярки

Mishanja

Новичок
UPDATE + регулярки

Добрый день!

Ситуация:

Есть column с категориями в VARCHAR(100) в которых названия категорий в виде: TV & FM Tuners, Cases, CPU и т.д.
Список категорий может меняться ежедневно.

Задача:

Создать колонку с кодом категории (для последующего сравнения с колонкой в другой таблице). Код видится как, ну скажем, 5 согласных букв идущих подряд от первой (можно конечно использовать md5, но мне кажется что сравнивать 5 символов Mysql будет быстрее ).

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

Заранее благодарю.
 

Mishanja

Новичок
маловероятно, и такая маленькая вероятность меня вполне устраивает
Там около 200 категорий, и сразу будет видно, если и будут совпадения, то можно будет 6 или 7 букв
 

Mishanja

Новичок
alpine

мож конечно я чего не понимаю, но:

эти категории находятся в таблице прайса поставщика, в котором ~30000 записей, каждому товару соответствует одна из ~200 категорий. Прайс я получаю в XML (curl забирает его, simplexml парсит в базу). Для того, чтобы запомнить какие категории товаров у какого поставщика берутся, есть отдельная табличка с категориями. Вот когда я получаю новый XML, чтобы заново не выбирать категории - нужна система (сейчас она реалзована на хэше md5), которая бы помнила, какие категории у кого мы берем. Дальше - больше - у каждой категории есть подкатегория, а у подкатегории - производитель. Вот я и подумал, что если есть всего 200 категорий, то почему бы не придумать им код - короче, чем md5. Ведь сравнение двух таблиц в одной из которых ~1000 записей (категории с которыми мы работаем) а в другой ~30000 записей будет быстрее, если сравнивать 5 символов, а не хэш md5.

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

-~{}~ 07.08.07 16:54:

По сути сабжа, может кто сказать что-то или здесь только те, кто может "куражиться, да насмехаться"?
 

Bitterman

Новичок
Mishanja
А почему нельзя сравнивать просто названия категорий? Зачем обязательно "цифровой код"?
 

Mishanja

Новичок
не обязательно "цифровой". Мне ближе буквенный, потому как не могу придумать как генерить уникальный цифровой код из названия категории. Ведь генерить его придется каждый раз после получения нового XML. И для одной и той же категории должен быть сгенерен одинаковый код.

Потому что бывают вот такие примеры:

Категория: Сумки и прочие акссессуары для видеокамер
Подкатегория: Аксессуары для видеокамер
Производитель: Canon

Т.е. сравнение надо производить по 3 этим полям. Вот я и подумал, что если заменить Категорию на ее код, сравнение будет намного быстрее происходить.

Дело в том, что это все 3 раза в день, для 10 поставщиков делается и мне надо чтобы оптимально быстро было.

Есть поставщики у которых в XML сразу коды категорий/подкатегорий есть, и если я провожу сравнение по их кодам, то выполнение в 1,5-2 раза быстрее происходит. Но есть некоторые поставщики без кодов категорий, в них и вся загвоздка.
 

Bitterman

Новичок
Дело в том, что это все 3 раза в день, для 10 поставщиков делается и мне надо чтобы оптимально быстро было.
Какая в этом принципиальная разница? Не все ли равно происходит этот UPDATE 10 секунд или 20?

Если надо записать код в отдельное поле, то, наверное, надо воспользоваться регулярными выражениями из ПХП при составлении запроса, а не регулярками MySQL.
 

Mishanja

Новичок
ну а все таки... в Mysql реально такой запрос составить или нет?

типа

UPDATE supplier SET `cat_code`=РЕГУЛЯРКА(`category`)
 

Mishanja

Новичок
Спасибо за ссылочку, там я уже был, и прочитав понял как его использовать с SELECT, про UPDATE там ничего нет

"Регулярные выражения (regex, regexp) представляют собой мощный способ выполнения сложного поиска."


Спасибо Bitterman за поддержание диалога, пойду бороздить просторы в поисках истины...
 

4m@t!c

Александр
А если один раз приедт TV&FM, а другой раз FM&TV. Я не совсем понял, по каком принципу формируется свзяь между таблица.
 

Mishanja

Новичок
это будет считаться разными категориями, ибо поскольку отсутствует у поставщика код категории, то ориентироваться приходится только на название. Типа поставщик название поменял для категории, все писец.

Вот связь:

1 таблица work_cats - типа категории с которыми работаем:

id cat_code sub_cat_code vendor


2 таблица supplier - прайс лист поставщика

id tovar cat_name cat_cide sub_cat_name sub_cat_code vendor price


Когда curl загружает новый прайс он парсится во 2 таблицу


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

Т.е. приходится сравнивать фактически 3 поля. На данный момент в полях с кодом находится md5(cat_name), но млин длинющий такой и долго сравнение происходит, хочется быстрее. ПОтому как оператор, который новые товары смотрит и выбирает - сидит и ждет пока сравнение закончится (хотя это все один раз делается, но все же).

Думаю, если вместо md5 поставить буквенный код, которых думается можно сделать одним запросом прямо в SQL а не перебирать всю таблицу PHP, то будет быстрее.

4m@t!c

Вы не знаете возможно ли использовать REGEXP в запросах UPDATE, или такая херня нафик никому не нужна, кроме меня?
 

Mishanja

Новичок
мешает не знание синтаксиса REGEXP в MYSQL.

Но вот я сейчас подумал, может регексп и не справится. Потому как судя по всему реги в мускуле все ж больше для поиска. Надо рыть наверное в сторону функций по работе со строками.
 

4m@t!c

Александр
Мне кажется, что вы идете не в ту сторону. Я бы остановился на хешах, которые строятся на основании строк, которые получаете. Я не понимаю логики работы и где именно тормоза, хоть убейте.
 

Mishanja

Новичок
4m@t!c
спасибо и вам за участие в диалоге...

alpine
спасибки за бестолковые комментарии

Не подвешен у меня так язык чтобы логику объяснить. Придется оставить все на хэшах.

Всем спасибо.
 

alpine

Новичок
Mishanja
Не подвешен у меня так язык чтобы логику объяснить. Придется оставить все на хэшах.
Доказать, что это у тебя является узким местом в приложении ты так и не смог. Поэтому я склонен считать, что проблема высосана из пальца.
 
Сверху