Разработка базы данных для системы голосования по продукту - PullRequest
0 голосов
/ 24 февраля 2011

Я создаю систему, в которой пользователь может голосовать за или против продукта, мне нужно иметь возможность четко определить количество взлетов и падений продукта, а также общий балл за последниеperiod.

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

Вот мои текущие предложенные таблицы:

Продукт
ID, name, category_id

Голосовать
ID, идентификатор пользователя, product_id, parent_id, комментарий, оценка, дата и время

Пользователь
ID, имя пользователя и т. Д.

ЯДумаешь, мне понадобится таблица комментариев, чтобы сделать это эффективно?Поле для подсчета голосов равно 1 или -1 согласно совету, который я прочитал в StackOverflow, который позволил бы мне собрать SUM() этого столбца для подсчета общего числа голосов, другой возможностью было бы иметь отдельные таблицы voice_up и voice_down..но я просто не уверен.

Ответы [ 3 ]

6 голосов
/ 24 февраля 2011

В зависимости от того, что вы хотите сделать, это может быть невероятно сложной проблемой, но вот мой взгляд на самый простой способ (например, что я могу бросить вместе за 10 минут, прежде чем я уйду с работы ;-P)

Я бы попробовал подход в стиле StackOverflow / HotOrNot и сохранил бы их рейтинг как целое число без знака.

PRODUCTS(
id, 
category_id, 
name, 
rating INTEGER UNSIGNED NOT NULL DEFAULT 0
);

Затем в вашей таблице «ГОЛОСОВАНИЕ» вы сохраняете Голосование (вверх / вниз). Я думаю, что таблица для вашей таблицы «VOTES» выглядит хорошо (хотя я бы использовал перечисление в качестве типа данных SCORE или какую-то стратегию, чтобы гарантировать, что голос не может быть обработан через XSS. Например, кто-то изменяет голосование так, что их голосование +10 000 вместо +1, тогда это было бы не круто)

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

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

Например, вот как работает алгоритм ранжирования Quora

Если пользователь является «опытным пользователем» или имеет более активную учетную запись, возможно, его голос важнее, чем голос нового пользователя. Я думаю, что на Yelp, если у вас не более одного или двух отзывов, ваш рейтинг и отзывы не будут учитываться, пока вы не встретите минимальное количество отзывов. Действительно, небеса предел.

PS. Я также рекомендовал бы проверить эту книгу О'Рейли о некоторых стратегиях для решения таких проблем

2 голосов
/ 17 мая 2013

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

Наивный подход может выглядеть примерно так (мои извинения, если я упрощаю ваш пример, и если T-SQL не ваш яд):

create table Products(
ProductId BIGINT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
Score     INT NOT NULL...
ProductDetails...

, где вы будете выполнять обновления Продуктов путем подведения итогов голосования.ПЛОХОЙ!

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

Лучшим способом было бы сбросить счет.столбец в целом, только вставьте в таблицы голосования вверх / вниз и выберите при необходимости.Нет причины, по которой вы не можете вычислить сумму в коде (например, PHP, C # или что-то еще), и это избавляет от необходимости когда-либо обновлять таблицу «Продукты» (по крайней мере, для вычисления балла).Другими словами, хранение таблицы «Оценка» в продуктах ничего не дает и просто не требует дополнительных затрат.

Я говорю по своему опыту, когда говорю, что обновления могут быть плохими в системах большого объема.Обновление дорого по сравнению со вставкой в ​​конце или выбором (при условии, что ваша таблица правильно проиндексирована), и в таких ситуациях очень просто неосознанно снять существенную блокировку.

1 голос
/ 24 февраля 2011

Книга Начало CakePHP содержит учебник по Ajax по внедрению рабочей системы голосования (вверх / вниз) по комментариям. Я сделал урок несколько лет назад. Я не уверен, насколько он безопасен или станет хорошей основой для вашего проекта, но, возможно, стоит взглянуть на некоторые идеи.

...