Возможности пользователя на сайте

Question

Я хочу создать систему на веб-сайте, которая позволяет пользователям делать что-то зависящее от их рейтинга. Например, у меня есть правило для рейтинга значение X:

• 1 пост в течение 3 дней
• 10 комментариев в 1 день
• 20 голосов 2 дня

для номинального значения Y, правило может быть следующее:

• 3 пост в 1 день
• 50 комментариев за 1 день
• 30 голосов в 1 день

Каждую ночь я пересчитывать рейтинги пользователей, так что я знаю, что каждый пользователь может сделать. Возможности не суммируются или не переустанавливаются при пересчете каждого рейтинга.

Еще одна важная вещь: администратор может заполнить конкретные возможности пользователя в любое время.

Что такое оптимальная структура базы данных (MySQL) для желаемого?

я могу рассчитывать, что конкретный пользователь сделал:

SELECT COUNT(*) FROM posts WHERE UserID=XXX AND DateOfPost >= 'YYY' 
SELECT COUNT(*) FROM comments WHERE UserID=XXX AND CommentOfPost >= 'YYY' 

Но как я могу сделать администратор возможность заполнения в этом случае?

Answer 1

Я бы ежедневно регистрировал количество действий каждого пользователя и использовал эту таблицу для сравнения.

Эта таблица будет содержать следующие поля:

• Дата: день, когда действие имело место
• количество: количество действий взяли в тот день
• идентификатор пользователя: кто сделал это действие
• action: какое действие сообщение/комментарий/vo тэ/...
• игнорировать: Boolean, если этот параметр установлен, администратор должен сбросить значения

Проверка правила: SELECT SUM (кол) FROM журнал, в котором идентификатор пользователя = XXX и действие = YYY и игнорировать = 0 и DATEDIFF (дата, NOW()) < = ДНЕЙ

Сброс правила: UPDATE игнорировать = 1 из журнала WHERE идентификатор пользователя = XXX

Если его рейтинг изменяет результат по-прежнему правомочно (вы просто сравните с другой на общей)

При создании правил таблицы:

• действие
• пределы
• дней
• rating_min
• rating_max

Вы можете запросить разрешения, как это:

SELECT action, IF(SUM(count) < MIN(limits), 1, 0) as can_do_action FROM log LEFT JOIN rules ON rules.action = log.action WHERE userId = XXX AND rating_min <= RATING AND rating_max >= RATING AND ignore = 0 AND DATEDIFF(date, NOW()) <= days 

Таким образом, вы получите таблицу Логгина так: - комментарий => 1 - голосов => 0

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

The abs что правило не означает никаких действий, поэтому мы можем его игнорировать.

Answer 2

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

===

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

Answer 3

Если вы правильно поняли, что у вас есть пользователь, который может опубликовать 1 блог и прокомментировать 10 раз. Теперь он/она прокомментировал 5 раз и разместил блог. Вы хотите, чтобы администратор нажал кнопку, и теперь пользователь может снова опубликовать блог и прокомментировать 10 раз?

Это может быть немного взломанный, но вы можете считать действия, которые были сброшены/проигнорированы, и вычесть из текущих действий?

e.g .: у пользователя есть 1 блог и 5 комментариев. Администратор нажимает «reset», и вы сохраняете эти значения. Теперь, когда посты пользователей другой блог, и вы убедитесь, что это разрешено, вы получите

SELECT COUNT(*) FROM posts WHERE UserID=XXX AND DateOfPost >= 'YYY' 

И вы сделать что-то вроде этого

SELECT changes FROM adminTable WHERE UserID=XXX AND type = 'post' 

И если кол - изменения в порядке, вы» сброс.

Answer 4

Я предлагаю разделяющей две проблемы полностью:

• процесс включения особенности/возможности для пользователей
• Модель данных пользователя имеется

Например, вы могли бы просто таблица «многие-ко-многим», представляющая пользовательские функции:

user_features(
    user_id 
    ,feature_id 
    ,source  (admin|earned) 
    ,primary key(user_id, feature_id) 
); 

Это позволяет администраторам легко отключить/включить части или весь набор функций.

Ваша ночная работа запрашивает соответствующие таблицы и предоставляет/отменяет функции, вставляя/удаляя из этой таблицы.

Если вы идете с этим подходом, вы можете фактически дать функции либо на основе рейтинга, либо конкретных действий.

Правило, такие как "3 сообщений в 3-х дней", может быть реализована следующим образом:

when a user posts, check if the previous post was made within 24 hours. 
if yes then 
    increment counter by 1 
    record current timestamp 

    if counter = 3 then 
     grant feature to user 
else 
    reset counter to 1 
    record current timestamp 

Вы бы нужны две колонки (POST_COUNT: Int, last_post: дата) в некоторой таблице шпонкой на user_id.