Формула репутации - лучший подход

Question

У меня есть таблица в Oracle, которая записывает события для пользователя. У этого пользователя может быть много событий. Из этих событий я рассчитываю репутацию по формуле. Мой вопрос заключается в том, что это лучший подход для расчета и возврата данных. Используя представление и используя SQL, делайте это в коде, захватывая все события и вычисляя его (проблема в этом, когда у вас есть список пользователей и вам нужно рассчитать репутацию для всех), или что-то еще. Хотелось бы услышать ваши мысли.

Comments * (.1) + 
Blog Posts * (.3) + 
Blog Posts Ratings * (.1) + 
Followers * (.1) + 
Following * (.1) + 
Badges * (.2) + 
Connections * (.1) 
= 100%

Один пример

Comments:

This parameter is based on the average comments per post.

•   Max: 20
•   Formula: AVE(#) / max * 100 = 100%
•   Example: 5 /10 * 100 = 50%

Макс это максимальное число, чтобы получить весь этот процент. Надеюсь, в этом есть какой-то смысл.

Мы рассчитываем посещение, поэтому все уникальные посещения / дата членства - другое. Таблица содержит имя события, некоторые метаданные и привязана к этому пользователю. Репутация просто использует эти события, чтобы сформулировать репутацию на основе 100% как самого высокого.

85% reputation - Joe AuthorUser been a member for 3 years. He has:
•   written 18 blog posts 
o   2 in the past month
•   commented an average of 115 times per month
•   3,000 followers
•   following 2,000 people
•   received an average like rating of 325 per post 
•   he's earned, over the past 3 years: 
o   100 level 1 badges
o   50 level 2 badges
•   he's connected his: 
o   FB account
o   Twitter account

Answer 1

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

Это может оказаться чем-то, что поможет при сохранении итогов, используемых для некоторых вычисленных значений. Например, посмотрите на вещи, которые вызывают DML. Если у вас была таблица user_reputation, то триггер в вашей таблице blog_post может увеличивать / уменьшать счетчик user_reputation при вставке или удалении сообщения. То же самое для комментариев, лайков, подписок и т. Д.

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

Не говорю, что это решение. Просто сказать, что это может стоить изучения.

Answer 2

В качестве общего подхода я бы использовал PL / SQL.Один пакет с несколькими функциями get_rep.

function calc_rep (i_comments in number, i_posts in number, i_ratings in number,
                  i_followers in number, i_following in number, i_badges in number,
                  i_connections in number) return number deterministic is
...
end calc_rep;

function get_rep_for_user (i_user_id in number) is
  v_comments ....
begin
  select .....
  calc_rep (v_comments...)
end get_rep_for_user;

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

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