声誉公式 - 最佳方法

发布于 2024-10-22 01:57:10 字数 1089 浏览 4 评论 0原文

我在 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

I have a table in Oracle that records events for a user. This user may have many events. From these events I am calculating a reputation with a formula. My question is, what is this best approach to do this in calculating and returning the data. Using a view and using SQL, doing it in code by grabbing all the events and calculating it (problem with this is when you have a list of users and need to calculate the reputation for all), or something else. Like to hear your thoughts.

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

One Example

Comments:

This parameter is based on the average comments per post.

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

Max is that maximum number to get all that percentage. Hope that makes some sense.

We are calculating visitation, so all unique visits / date of membership is another. The table contains an event name, some meta data, and it is tied to that user. Reputation just uses those events to formulate a reputation based on 100% as the highest.

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

染火枫林 2024-10-29 01:57:10

作为一般方法,我将使用 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 是确定性的,因为具有相同一组数字的任何人都会得到相同的结果。

如果评论数等存储在一条记录中,那么调用起来就会很简单。如果需要汇总详细信息,则使用物化视图进行汇总。如果需要从多个地方收集它们,则可以使用视图来封装连接。

As a general approach I would be using PL/SQL. One package with several get_rep functions.

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;

If you've got to recalculate rep for a lot of users a lot of the time, I'd look into parallel pipelined functions (which should be a separate question). The CALC_REP is deterministic as anyone with the same set of numbers will get the same result.

If the number of comments etc is stored in a single record, then it will be simple to call. If the details need to be summarised up, then use materialized views for the summaries. If they need to be gathered from multiple places, then a view can be used to encapsulate the joins.

凉月流沐 2024-10-29 01:57:10

是否能够足够快地进行动态计算以满足要求,是数据量、数据库设计、最终计算复杂性等因素的一个因素……想象我们可以为您提供一种现成的方法是不合理的。

通过存储用于某些计算值的摘要可能会有所帮助。例如,看看导致 DML 的事情。如果您有一个 user_reputation 表,那么 blog_post 表上的触发器可以在插入或删除帖子时增加/减少 user_reputation 上的计数器。评论、点赞、关注等也是如此。

如果您以这种方式使所有摘要保持最新,那么 DML 的增量成本将很小,计算也会变得简单。

并不是说这是解决方案。只是说这可能值得探索。

Whether you can calculate on the fly fast enough to meet requirements is a factor of data volumes, database design, final calculation complexity..... to imagine that we can give you a cut-and-dry approach is unreasonable.

It may wind up being something that would be helped by storing summaries used for some calculated values. For example, look at the things that cause DML. If you had a user_reputation table, then a trigger on your blog_post table could increment/decrement a counter on user_reputation on insert or delete of a post. Same for comments, likes, follows, etc.

If you keep all of your summaries up to date in that manner, then the incremental costs to DML will be minor and the calculations will become simple.

Not saying that this is THE solution. Just saying that it might be worth exploring.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文