Есть скрипт каталога товаров с базой данных примерно следующей структуры:

Id (ид товара)
name (наименование)
desc (описание)
rating (рэйтинг)

Рэйтинг соответствует количеству просмотров данного товара за всё время. Т.е. при каждом клике на изображение товара, рейтинг увеличивается на единицу.

Добавил в таблицу дополнительные поля:
r_1 (количество просмотров за последний месяц)
r_2 (количество просмотров за последние 6 месяцев)
r_3 (количество просмотров за последний год)

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

Кто нибудь решал подобную задачу?

Можно просто создать таблицу:
id
id-товара
ye - год
me - месяц
de - день
h - час
i - минуты
s - секунды

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

Думаю, что придется хранить данные по месяцам, как Вы и предположили. В таких случаях приходится создавать таблицу с данными, делая шаг в минимальный по протяженности отрезок времени (то есть, как у Вас - 1 месяц).

EuGen
А чем мой вариант не подходит, чтоб можно было вообще, в любой момент изменить условия вывода рейтинга?

Тем, что Ваш вариант по сути, можно и правильнее сделать так: создать таблицу, куда записывать только одно поле - дату клика (вместе со временем). А при выводе пользователю считать COUNT по этой таблице. Конечно, такое построение даст возможность считать рейтинг за любой промежуток времени.
Но. Представьте себе, что у нас хотя бы 100000 кликов в день.. Это будет 36500000 записей за год. И самое главное, что нет ни одного поля, по которому бы можно было создать индекс (поле по сути одно и оно индекс по нему будет иметь слишком высокое значение CARDINALITY). И если мы захотим выбрать COUNT из такой таблицы, это приведет к жутко тормозному FULL SCAN (так как нет индексов).
Поэтому лучше хранить данные в уже агрегированном виде, когда достаточно знать число посещений за месяц. Правда, в этом случае мы будем знать число посещений именно за календарный, а не астрономический, месяц. (То есть если сейчас, к примеру, 6-е число, то мы не сможем узнать число посещений с 6-го мая по 6-е июня, а только с 1-го мая по 1-е июня).

Тогда может проще будет сделать
Id – ид товара
timestamp – дата просмотра


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



Про каленадрные периоды тоже думал. В принципе это устраивает. Т.е. когда пользователь кликает на ссылку "лучшие товары за 3 месяца", он получит выброку лучших товаров за 3 предыдущих месяца, без учёта текущего. Например, если сегодна 6-е июня, то выборка будет произведена за период с 1-е марта по 31 мая.

Сейчас вот думаю, може быть лучше привести таблицу к следующему виду:
Id (ид товара)
name (наименование)
desc (описание)
rating (рейтинг)
rm_1 (количество просмотров за январь)
rm_2 (количество просмотров за февраль)
rm_3 (количество просмотров за март)
...
rm_12 (количество просмотров за декабрь)

Тогда для того что бы выбрать лучшие товары за 3 месяца запрос будет выглядеть следующим образом