модель БД голосования, производительность

Question

например, сайт, где пользователи могут голосовать по вопросам (вверх и вниз) с этой моделью:

    users(id)

    questions(id)

    votes(id,userId,questionid,vote)  
-- vote can be +1 or -1, or probably better bit 0 and 1

Я думаю, что когда будет много questions с большим количеством голосов, возникнут проблемы с производительностью, особенно при отображении списка вопросов, поэтому

имеет ли смысл добавить столбец к таким вопросам:

questions(id, votessum)

и каждый раз, когда кто-то голосует, кроме того, что он делает insert into the votes questions also to update the questions и устанавливает его votessum column

Answer 1

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

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

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

Answer 2

Прежде чем беспокоиться о производительности, я бы больше беспокоился о точности и захвате всех данных.

Я бы создал отдельную таблицу с именем QuestionVotes со столбцами как QuestionId, UserId, VoteType, TimeStamp для захвата всех связанных действий.

Это поможет отследить все голоса, их тип, кто проголосовал, предотвратить двойные голоса и т. Д.

Теперь я могу рассмотреть вопрос об обновлении счетчика в таблице «Вопросы», если производительность ухудшится, но я бы сначала пошел по пути индексации и настройки запросов.