Алгоритм "тегов" на beta.ya.ru

E
На сайте с 27.12.2004
Offline
102
504

Создал топик с целью уточнить верно ли я рассматриваю алгоритм создания "тегов". В итоге должно получится что-то вроде beta.ya.ru

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

Итак, мой вариант реализации оного:

Предположим в профиле есть 3 поля:

Увлечения (поле fav) - содержит увлечения через запятую

Хобби (поле hob) - содержит хобби через запятую

возраст (поле age) - содержит возраст юзера.

Итак есть у нас 10000 юзеров.

Моя идея заключается в создании таблицы tags, которая состоит из полей:

tag - тег (слово)

type - тип тега (к какому полю относится: Увлечения, Хобби или Возраст)

value - количество совпадений

При добавлении информации в профиль - в таблицу профиля все данные вводятся "как есть", а для таблицы с тегами все теги делятся на массивы (если слова введены через запятую) и соответственно добавляются каждый отдельно. Если есть совпадения с данным тегом - значит новая строка не добавляется, а лишь value соответствующей строки увеличивается на 1, если же нет, то создается новая строка с новым тегом и значением value=1

При отображении информации в профиле. Идёт один запрос в таблицу с тегами где теги профиля сверяются с тегами в таблице и делается вывод циферки возле каждого слова.

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

ЗЫ: Обновление таблицы с тегами также можно делать кроном ночью. Чтобы скрипт сам составлял статистику каждый день и всё. Дабы не грузить его запросами во время большого количества юзеров онлайн.

Если я не прав, скажите пожалуйста в чём :) Если прав - тоже скажите.

Спасибо!

"Типичный говнарь противопоставляет себя «толпе», считает себя нонконформистом и уникальным человеком — несмотря на то, что говнарей огромные толпы и все они одинаковые." (lurkmore)
Коля Дубр
На сайте с 02.03.2005
Offline
153
#1

Зачем хранить данные, которые можно вычислить? :) Так быстрее? А кто сказал, что это - узкое место? Не стоит оптимизировать еще не написанный код ;)

Навскидку за 15 минут придумал что-то такое.

Имеем 3 таблички - fields, values, и profiles, последняя устанавливает связь "пользователь - параметр - значение". Выбираем все параметры, для которых пользователь №1 указал хотя бы одно значения, и кол-во пользователей, указавших такое же значение:


SELECT
F.name,
V.value,
F.id field_id,
(
SELECT
COUNT(*)
FROM
profiles OP
WHERE
OP.user_id != 1 AND
OP.field_id = P.field_id AND
OP.value_id = P.value_id
) as more
FROM
profiles P,
`fields` F,
`values` V
WHERE
P.user_id = 1 AND
F.id = P.field_id AND
V.id = P.value_id
ORDER BY
F.id

Получаем что-то вроде:


name value field_id more
Знаю языки немецкий 1 0
Знаю языки английский 1 2
А ещё я умею делать сайты 2 1

Остается в цикле обработать повторяющиеся параметры. При подсчет колонки "more" идет поиск по табличке, состоящей из трех числовых столбцов - подозреваю, что здесь узкого места возникнуть не должно. Даже если каждый пользователь заполнит по 10 значений для 10 параметров, мы получим вполне приемлимый миллион записей :) Поиск по текстовым полям (и то, типа VARCHAR) идет только при изменении профиля, что бывает не слишком часто.

Обратите внимание, параметры не фиксированные - можно добавить собственный параметр с собственным же значением, в случае ya.ru это реализовано как "Особенное". Собственно, попробуйте поизучать, какие еще выборки реализованы в ya.ru, примеряя на свою модель - увидите, где могут возникнуть проблемы.

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

Разрабатываю общую шину (http://habrahabr.ru/company/floxim/blog/268467/) помаленьку. ...а еще у меня есть бложек (http://www.blogovo.ru/).
E
На сайте с 27.12.2004
Offline
102
#2

Действительно решение уникальное :)

Я просто синтаксис ещё не настолько изучил, чтобы столь сложные запросы писать :)

Спасибо большое за подсказку!

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий