Обработка голосов вверх / вниз на сайте социальных новостей

Question

Я пытаюсь сделать Reddit-подобное веб-приложение с нуля. Я не уверен, как сохранить голоса «за» и «против».

Я думаю о создании таблицы с именем 'user_votes' с полями 'id', 'user_id', 'voted_link_id', 'up_or_down'

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

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

Я не знаком с веб-приложениями, сильно зависящими от БД. Пожалуйста, ведите меня.

P.S. Какие столбцы должны быть проиндексированы?

Answer 1

На самом деле вам нужны оба.

У вас должна быть таблица с Article_ID, User_ID, +1 или -1.Это именно по тем причинам, которые вы указали.Вам нужно будет показать голоса пользователя как действующий аккаунт.Вы также нам, что для обеспечения уникальности.

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

Вместо этого вы должны оставить два счетчика в таблице статей: общее количество положительных голосов и общее количество отрицательных голосов.Причина для двух заключается в том, что сумма несущественна, поскольку два значения находятся в одной строке.Во-вторых, вы можете захотеть реализовать что-то, что представит эти значения, как это делает SO.(Вы не сможете увидеть это, пока не наберете столько очков (около 1500)).

Возможно, вы захотите показать список статей и общее количество баллов, которые есть у каждого ... вы не хотите СУММАТЬнад таблицей голосов для длинного списка статей.Вы также можете разрешить людям устанавливать ограничения на статьи, «показывай мне только более +10».Опять же, вы не хотите суммировать по таблице голосов каждый раз, когда кто-то открывает свою домашнюю страницу.

Answer 2

Во-первых, это хорошо, что вам нравится этот вызов!

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

Итак, я бы начал с записи каждогоголосовать и подсчитывать общий балл на лету.Таким образом, вам не нужно иметь дело с тем, что происходит, когда ваш «подсчитанный балл» не синхронизируется с голосами (например, из-за сбоя приложения между записью голоса и обновлением итога).

Как только у вас появится этот дизайн, найдите способ протестировать производительность с огромными объемами данных и большими объемами посетителей.DBMonster и Apache JMeter могут быть инструментами для использования здесь.

Когда вы сталкиваетесь с проблемами производительности, попробуйте сначала решить их с помощью оптимизации запросов и индексации - используйте Stack Exchange в полной мере!Также обратите внимание на кеширование на уровне приложения.

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

Answer 3

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