Блог

Главная - Вопросы по программированию - Пропускаю ли я что-нибудь в этой реализации «голосования», используя ASP.NET MVC / C # / SQL?

Пропускаю ли я что-нибудь в этой реализации «голосования», используя ASP.NET MVC / C # / SQL?

#c# #sql #asp.net-mvc

#c# #sql #asp.net-mvc

Вопрос:

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

Таблица SQL

  • PageId BigInt FK PK
  • Идентификатор пользователя BigInt FK PK
  • Проголосуйте за TinyInt
  • DateVoted Дата-время

PageId и userId вместе являются PK для таблицы. Возможные значения для поля «Голосование» равны 1 и -1. Для поля DateVoted будет установлено значение DateTime.UtcNow при голосовании.

Есть ли поля, которые я пропускаю, которые вы считаете важными?

Реализация на странице будет отдаленно похожа на YouTube.

Комментарии:

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

2. Спасибо, Мерлин. О голосовании прокомментируйте один раз, сделав PageId и userId PK записи, что приведет к появлению уникального, то есть 1 голоса. Теперь о ложных учетных записях пользователей… хммм … в моем случае приложение использует учетные записи Facebook, поэтому я полагаю, что это будет сложно.

3. Если вы используете аутентификацию в другой системе, то вам, вероятно, не придется беспокоиться об этом так сильно. Facebook может использовать captcha, например, при создании учетной записи. Вы действительно ничего не можете сделать против кого-то достаточно решительного (кто-то нанимает людей для обработки captcha), но неплохо бы немного подумать о вероятных последствиях и потенциальном риске 🙂

Ответ №1:

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

Обратите внимание, что tinyint не подписано, поэтому -1 не является вариантом. Поэтому я бы использовал bit вместо этого (0 = отрицательный результат, 1 = положительный результат).

Комментарии:

1. Используя bit , он должен был бы убедиться, что он поддерживает удаление записей, либо с помощью true delete, либо с deleted флагом. Таким образом, пользователь может отменить свой голос, если он случайно нажал.

2. Верно. Я предположил, что он все равно захочет это сделать.

3. @Jonathan: Если он выполняет работу для существующего проекта, и они используют флаги мягкого удаления, он может не знать, что нужно это включить. Просто подумал, что это стоит упомянуть 🙂 О, также 1 за bit .

4. Отличные комментарии, я не подумал об этом сценарии (пользователь случайно проголосовал или хотел отменить голосование). Спасибо за bit совет.

5. Есть ли какие-либо поля, которые вы считаете важными? Я полагаю, что то, что я изложил, поддержало бы сценарий приложения, но, возможно, мне чего-то не хватает (из-за отсутствия опыта разработки такого рода функций)?