Как подсчитывать и хранить голоса для веб-сайта?

Question

Я использую SQL Server 2005.

У меня есть сайт, на котором люди могут голосовать на удивительных мотоциклах. Каждый раз, когда пользователь голосует, есть один для первого байка и один голос против второго байка. В базе данных хранятся два голоса. Таблица голосования выглядит так:

VoteID VoteDate  BikeID Vote 
1  2012-01-12 123 1 
2  2012-01-12 125 0 
3  2012-01-12 126 0 
4  2012-01-12 129 1 

Я хочу часто подсчитывать голоса за каждый велосипед, скажем, каждый час. Моя идея состоит в том, чтобы сохранить счет в процентах от выигранного конкурса против потерянного на велосипедном столе в качестве атрибута байка. Итак, если байк выиграл 10 конкурсов и проиграл 20 соревнований, у них будет счет (33). Я бы подсчитал ежедневные, еженедельные и ежемесячные баллы.

BikeID BikeName DailyTally WeeklyTally MonthlyTally 
1  Big Dog 5   10   50 
2  Big Cat 3   15   40 
3  Small Dog 9   8   0 
4  Fish Face 19   21   0 

Прямо сейчас, осталось около 500 голосов в день. Мы ожидаем 2500 - 5000 в день в следующем месяце или около того.

Каков наилучший способ подсчета данных и наилучший способ их хранения? Должны ли счета быть на своем столе? Должен ли триггер использоваться для запуска новой таблицы каждый раз, когда проголосовали байк? Следует ли хранить хранимую процедуру ежечасно, чтобы получить все счета?

Любые идеи были бы очень полезны!

Answer 1

Сохраните VoteDate как значение datetime вместо date.

Для ваших узоров вы можете просто сделать это представление и рассчитать его на лету. Это должно быть очень просто сделать, используя функции GROUP BY и DATEPART. Если вам нужен точный код, как это сделать, откройте новый вопрос.

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

Answer 2

Я согласен с @JNK попробовать просмотр или просто обычную хранимую процедуру для вычисления выходов на лету. Если вы обнаружите, что это будет слишком медленно по мере роста ваших данных, я бы исследовал другие маршруты (например, кеширование данных в другой таблице и т. Д.). Наверное, стоит держать его простым для начала; вы всегда можете повторно использовать логику из SP/VIEW позже, если хотите настроить запланированную задачу.

Edit: Убрана индексный просмотр, как в @Damien_The_Unbeliever комментарии его не детерминированным и я глупо :)