Сортировать по количествую раз определенного символя в поле

[Сенсей]

Сортировать по количествую раз определенного символя в поле

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

Например если в поле имеются данные: "любить, курить, пить, водить, программировать"

Символ ", " встречается 4 раза. Вот по нему надо сортировать.

Если говорить проще - нужен аналог substr_count из php

Пока заюзал MATCH с сортировкой по релевантности.

$res = sql_query("SELECT b.user_id, b.user_nick, b.user_sex, b.user_city_id, b.user_avator, b.user_avator_path, MATCH (b.user_interests) AGAINST (',' IN BOOLEAN MODE) as relev, b.user_able 
FROM ".$prefix."_users b where b.user_interests != '' order by relev DESC limit 20
", $dbi);

Результат нужный получен. Но что то смущает меня использование полнотекстового поиска для этой задачи... есть еще мысль заюзать REGEXP в запросе.

Задача вроде самая что ни есть простая... а вот застрял...

 

[zerkms]

вот ещё один извратный вариант в копилку:

[sql]
LENGTH(`field`) - LENGTH(REPLACE(`field`, ',', ''))
[/sql]

 

[Сенсей]

zerkms
Я прогнал... мой вариант не подходит... так как MATCH в основном ограничен ft_min_word_len=3 и не спроста я так думаю...

А твой извратный способ походу единственно верный... все гениальное просто =))

 

[Gas]

zerkms
отличный "альтернативный" вариант

Сенсей
если нужны такие операции, почему не сделать по-науке - отношение one-to-many или many-to-many

 

[Wicked]

Сенсей
а нельзя пару слов о том, зачем такое извращение вообще могло понадобиться?

 

[Сенсей]

Да вобщем то все просто до безобразия... у юзеров есть интересы... интересы разделяются запятыми...

у кого зяпятых больше - тот и интереснее... вот и надо мне выбрать с понтом 10 самых интересных людей =))

Решил не заморачиваться с продумыванием системы кого считать интересным и т.д. Может конечно и тупо, но задача то простенькая совсем... жаль нет функции в мускуле специальной для этого...

 

[Mr_Max]

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

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

 

[berkut]

вот так категорично не стоит. всё больше убеждаюсь, что без денормализации полная жопа, а нормализация - понты

 

[Сенсей]

То есть ты предлагаешь вместо того что я щас делаю:

На входе:
1. Получил данные от пользователя (например строка: "отдыхать, пить пиво, секс, знакомиться")
2. Сохранил в таблице users в поле user_interests

На выходе:
1. Выбрал поле user_interests из таблицы users
2. Explode по ","
3. Вывод в цикле <a href="/search?tag=$key">$key</a>
4. Вывод юзеров с похожими интересами - простое LIKE

Делать вот так?

База: создать доп 2 таблицы (table_interests_words и table_inerests_data) В 1-ой хранить слова+word_id а во 2-ой хранить связь user_id + word_id

На входе:
1. Получил данные от пользователя (например строка: "отдыхать, пить пиво, секс, знакомиться")
2. Explode по ","
3. Проверяем если слова в table_interests_words уже существуют - берем их ID и просто делаем связь в table_inerests_data
4. Если слова не существуют - добавляем слова в таблицу table_interests_words, потом связь в таблицу table_inerests_data

На выходе:
1. Дополнительный запрос в базу для вывода привязанных к юзеру word_id и самих слов. Join нам в помощ.
2. Вывод в цикле <a href="/search?tag=$word_id">$word</a>
4. Вывод юзеров с похожими интересами - через дополнительные запросы к 2-ум таблицам которые мы создали


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

з.ы
Где плюсы?

 

[berkut]

Сенсей плюсов море. даже именно при таком раскладе,
нормализованная будет быстрее, чем строковые функции + куча возможностей для других статистических запросов. но если хранить как у тебя, то как минимум нужно interest преобразовывать в SET type. там ваще лафа

 

[zerkms]

вот так категорично не стоит. всё больше убеждаюсь, что без денормализации полная жопа, а нормализация - понты

тебе тоже так категорично, наверное, не надо высказываться
пока проблем нет - смысл денормализироваться?

 

[Сенсей]

Вот сейчас подумал и нашел один плюс...

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

Вопрос только в производительности... если сейчас например я беру поле с кейвордами одновременно с общими данными пользователя.... то есть в одном запросе... то в варианте с отдельными таблицами мне нужно будет соединять 3 таблицы...

Какие все таки совет будут? Проэкт расчитан на 50k регистраций и примерно 200-400 хитов в день.

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