Вы упомянули об этом в запросе SQL, поэтому я приведу примеры в этом.
Если у вас есть таблица / представление Pages
, что-то вроде этого
Pages
-----
page_id:int
views:int - indexed
comments:int - indexed
Тогда вы можете заказать их, написав
SELECT * FROM Pages
ORDER BY
(0.3+LOG10(10+views)/LOG10(10+(SELECT MAX(views) FROM Pages))) +
(0.7+LOG10(10+comments)/LOG10(10+(SELECT MAX(comments) FROM Pages)))
Я сознательно выбрал неравный вес между представлениями и комментариями. Проблема, которая может возникнуть при сохранении равного веса с представлениями / комментариями, состоит в том, что ранжирование становится самоисполняющимся пророчеством - страница возвращается вверху списка, поэтому она посещается чаще и, таким образом, получает больше очков, поэтому отображается в конце списка, и его посещают чаще, и он получает больше баллов .... Повышение внимания к комментариям свидетельствует о том, что они требуют реальных усилий и проявляют реальный интерес.
Приведенная выше формула даст вам рейтинг на основе статистики за все время. Таким образом, статья, собравшая столько же просмотров / комментариев за последнюю неделю, что и другая статья за последний год, будет иметь такой же приоритет. Возможно, имеет смысл повторить формулу, указав каждый раз диапазон дат и отдавая предпочтение страницам с более высокой активностью, например
0.3*(score for views/comments today) - live data
0.3*(score for views/comments in the last week)
0.25*(score for views/comments in the last month)
0.15*(score for all views/comments, all time)
Это гарантирует, что «горячим» страницам будет присвоен более высокий приоритет, чем страницам с аналогичными оценками, которые в последнее время не видели много действий. Все значения, кроме сегодняшних оценок, могут быть сохранены в таблицах с помощью запланированных хранимых процедур, так что базе данных не нужно собирать множество комментариев / просмотреть статистику. Только сегодняшняя статистика вычисляется «вживую». Сделав еще один шаг вперед, сама формула ранжирования может быть вычислена и сохранена для исторических данных с помощью хранимой процедуры, выполняемой ежедневно.
РЕДАКТИРОВАТЬ: Чтобы получить строгий диапазон от 0,1 до 1,0, вы должны мотивировать формулу, как это. Но я подчеркиваю - это только добавит накладных расходов и не является необходимым - абсолютные значения приоритета не важны - только их относительные значения к другим URL-адресам. Поисковая система использует их для ответа на вопрос, является ли URL A более важным / релевантным, чем URL B? Он делает это, сравнивая их приоритеты - какой из них наибольший, - а не их абсолютные значения.
// ненормализовано - x это некоторый идентификатор страницы
un (x) = 0.3 * log (просмотров (x) +10) / log (10 + maxViews ()) +
0.7 * Log (комментарии (х) + 10) / журнал (10 + maxComments ())
// исходная формула (теперь в псевдокоде)
Максимум будет равен 1,0, минимум будет начинаться с 1,0 и двигаться вниз по мере увеличения количества просмотров / комментариев.
мы определяем un (0) как минимальное значение, т. Е. (Где views (x) и comments (x) равны 0 в приведенной выше формуле)
Чтобы получить нормализованную формулу от 0,1 до 1,0, вы затем вычисляете n (x), нормализованный приоритет для страницы x
(1.0-un(x)) * (un(0)-0.1)
n(x) = un(x) - ------------------------- when un(0) != 1.0
1.0-un(0)
= 0.1 otherwise.