Регулярное выражение в mysql

[solovin1986]

Задача такова: в таблице есть специальное дополнительное поле

для примера

brend|nike||madein|chine||size|43,450||и.тд.

нужно сделать выборку через REGEXP размеров от 42,5 скажем до 43,4 не пойму как составить от и до

[Veseloff]

А зачем regexp? Или это так выглядит содержимое ячейки? Если да, то какой в этом смысл? Если уж совсем никак, то что-нибудь типа такого попробовать

(42,[5-9]\d*|43|43,[0-4]|43,[0-3]\d*)

Но советую так никогда больше не делать. И это привести в нормальный вид.

[solovin1986]

А зачем regexp? Или это так выглядит содержимое ячейки? Если да, то какой в этом смысл? Если уж совсем никак, то что-нибудь типа такого попробовать

(42,[5-9]\d*|43|43,[0-4]|43,[0-3]\d*)

Но советую так никогда больше не делать. И это привести в нормальный вид.

Да так выглядит содержимое ячейки.

Есть бд на 137 000 товаров и там вот так хранятся данные задача вывести в поиске товары в диапазоне.

[SelenIT]

Нормализовать базу СРОЧНО, пока она не разрослась до миллиона записей (впрочем, поисковый движок, лишенный помощи индексов, наверняка схлопнется под такой нагрузкой еще раньше). А того, кто написал этот кошмар, заставить съесть 137 кило мешанины из хлебных крошек, масла, мелко нарезанной колбасы и джема — пусть прочувствует наглядно, так сказать...

[Veseloff]

Оягребу. Регэксп просматривает каждую запись, отчего сервер скрипит как старая телега. Вы и правда считаете, что так можно делать?

[solovin1986]

Ок. Еще вопрос что можно еще сделать кроме того как разбить все по полям?

Edited July 4, 2011 by solovin1986

[alanvanduke]

Ок. Еще вопрос что можно еще сделать кроме того как разбить все по полям?

Разбить все по полям и написать нормальные SELECT-запросы.

Edited July 4, 2011 by alanvanduke

[SelenIT]

Я бы в качестве первого шага к нормальной базе вынес это безобразие в отдельную таблицу вида ID товара — имя характеристики — значение характеристики (потом можно будет имена характеристик систематизировать и вынести в третью таблицу, разнести по разным таблицам текстовые и числовые значения... но для начала и это прогресс). Отношение "много к одному". По всем полям раздельные индексы. А дальше что-нибудь типа SELECT DISTINCT good_id FROM goods_properties WHERE property_name = 'size' AND property_value BETWEEN '42,5' AND '43,4' — и айдишки товаров, для которых есть подходящие размеры, у нас в кармане...

[alanvanduke]

Я бы в качестве первого шага к нормальной базе вынес это безобразие в отдельную таблицу вида ID товара — имя характеристики — значение характеристики (потом можно будет имена характеристик систематизировать и вынести в третью таблицу, разнести по разным таблицам текстовые и числовые значения... но для начала и это прогресс). Отношение "много к одному". По всем полям раздельные индексы. А дальше что-нибудь типа SELECT DISTINCT good_id FROM goods_properties WHERE property_name = 'size' AND property_value BETWEEN '42,5' AND '43,4' — и айдишки товаров, для которых есть подходящие размеры, у нас в кармане...

Для начала я бы предложил просто прочитать книжку умную "Что такое базы данных", а уже потом действовать. Толку-то, если человек не понимает принципов построения релиативных баз данных, и хранит данные "по старинке", как в файлах.

Ключевые слова "нормализация базы данных".

Edited July 4, 2011 by alanvanduke

[solovin1986]

Я бы в качестве первого шага к нормальной базе вынес это безобразие в отдельную таблицу вида ID товара — имя характеристики — значение характеристики (потом можно будет имена характеристик систематизировать и вынести в третью таблицу, разнести по разным таблицам текстовые и числовые значения... но для начала и это прогресс). Отношение "много к одному". По всем полям раздельные индексы. А дальше что-нибудь типа SELECT DISTINCT good_id FROM goods_properties WHERE property_name = 'size' AND property_value BETWEEN '42,5' AND '43,4' — и айдишки товаров, для которых есть подходящие размеры, у нас в кармане...

Для начала я бы предложил просто прочитать книжку умную "Что такое базы данных", а уже потом действовать. Толку-то, если человек не понимает принципов построения релиативных баз данных, и хранит данные "по старинке", как в файлах.

Ключевые слова "нормализация базы данных".

Спасибо за рекомендацию но мои действия отталкиваются из ограниченного бюджета а не от непонимания.

В принципе ни в одной книге не написано какой объем данных влияет на то или иное. И как это лучше всего реализовать исходя из того или другого. А делается это на страх и риск программистов и проектировщиков. Даже 3 таблицы делать тоже не самый лучший вариант.

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

Тут нужны рекомендации большого спеца в данном направлении.

Edited July 5, 2011 by solovin1986

[Veseloff]

Спасибо за рекомендацию но мои действия отталкиваются из ограниченного бюджета а не от непонимания.

В принципе ни в одной книге не написано какой объем данных влияет на то или иное. И как это лучше всего реализовать исходя из того или другого. А делается это на страх и риск программистов и проектировщиков. Даже 3 таблицы делать тоже не самый лучший вариант.

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

Тут нужны рекомендации большого спеца в данном направлении.

А просматривать каждую строчку — лучший вариант? По-моему, так 3 таблицы вполне себе хорошая структура для хранения данных. У меня, например, для хранения каталога на сайте используются 14 таблиц и работает это всё достаточно быстро, так как используются индексы. Вообще делать выборки без индекса — абсолютное зло. Не стоит бояться большого количества таблиц, стоит бояться плохих запросов. Чтобы определить качестов запроса достаточно посмотреть EXPLAIN. Для варианта с регэкспом будут просмотрены все 137к записей и ещё регэксп будет к ним применён. А хранить числа в текстовых полях — вообще бред сивой кобылы.

[Micks]

Спасибо за рекомендацию но мои действия отталкиваются из ограниченного бюджета а не от непонимания.

В принципе ни в одной книге не написано какой объем данных влияет на то или иное. И как это лучше всего реализовать исходя из того или другого. А делается это на страх и риск программистов и проектировщиков. Даже 3 таблицы делать тоже не самый лучший вариант.

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

Тут нужны рекомендации большого спеца в данном направлении.

А просматривать каждую строчку — лучший вариант? По-моему, так 3 таблицы вполне себе хорошая структура для хранения данных. У меня, например, для хранения каталога на сайте используются 14 таблиц и работает это всё достаточно быстро, так как используются индексы. Вообще делать выборки без индекса — абсолютное зло. Не стоит бояться большого количества таблиц, стоит бояться плохих запросов. Чтобы определить качестов запроса достаточно посмотреть EXPLAIN. Для варианта с регэкспом будут просмотрены все 137к записей и ещё регэксп будет к ним применён. А хранить числа в текстовых полях — вообще бред сивой кобылы.

ладно числа в текстовых полях, когда тут нарушается 1NF и вся "прелесть" использования БД теряется. Нормальная Форма читайте в общем

[Junglekag]

Нужно составить регулярное выражение для функции UPDATE в MySQL, что бы UPDATE убивало все ссылки в постах.

UPDATE zoloto_1000.wp_posts SET post_content = REPLACEpost_content, "<a style="................">", ""

Как это сделать?

—

я использую XRumer 7.0 Elite за лучшее продвижение нафорумах