Question

只是寻找一些关于如何处理数据库设计的建议。

在我的网站上，用户可以获得执行不同活动的积分。目前我有三项活动可以获得积分 - 但设计必须是可扩展的，我可以在其中添加其他活动以获得积分。

所以今天 - 用户获得积分 1）当他添加新店时，他获得10分（商店信息存储在STORE表中） 2）当他回答问题时，他获得7分（问题/答案存储在ANSWERS表中） 3）当他提到加入该网站的朋友时，他得到5分

所以这就是我到目前为止 - 但看起来并不正确：）

Points_Table point_id 用户身份动作（这将捕获给出的点的动作）点

我应该能够从数据库中推断出该用户获得了xxxx积分来创建这个商店或者引用这些朋友或回答这个问题。上述设计显然没有考虑到这一点。

感谢您的提示

Answer 1

添加一个表，用于存储用户获取点数的操作（列出指向不同表中实际操作的操作的通用表）。该表可能类似于Reward_Actions（ActionId，ActionType，Points points）等等，您可以通过此方式添加不同类型的奖励行动。

Answer 2

根本不存储积分。只需对此视图进行查询。这样，面对任意变化，它将是强大的。

create view UserPoints
as
select
    created_by_id as user_id,
    'STORE' as action_type,
    store_id as action_id,
    (select points from action_points where action_desc='create store') as points
from store
union
select
    user_id,
    'ANSWER' as action_type,
    question_id as action_id,
    (select points from action_points where action_desc='answer question') as points
from answer
union
select
    referred_by_id as user_id,
    'REFERRAL' as action_type,
    referred_id as action_id,
    (select points from action_points where action_desc='referral') as points
from referral

编辑添加：

这遵循正常的数据库设计原则。所有数据库规范化都可以用这个来概括：不要重复数据。

包含点表基本上只是重复数据库其余部分已包含的信息。因此，应该省略。在考虑必须保持数据一致性的长度时，这一点很清楚。在不担心这些要点的情况下，如果将推荐归因于Alice，但是稍后确定Bob应该接收该积分，则这将需要改变单个表的单行中的单个字段。如果包含点表，则还必须以某种方式更新点表。如果存储点汇总，那么上帝可以怜悯你的数据库。

不是存储点，而是可以使用视图或存储过程，然后在数据发生变化时自动调整点系统。

我认为在这种情况下，一个视图对于存储过程是可以接受的，因为有许多方法可能需要分析点数据，这提供了最大的灵活性，并且它为优化器提供了识别的最佳机会最佳路径。

您可以通过user_id或action_type从视图中进行选择，或者对点列进行求和，以获得用户或所有用户的总计。看看你可以拥有的乐趣，它实际上是免费的！

select
    sum(up.points) as total_points,
    up.user_id,
    u.user_name
from
    UserPoints up
    join user u on up.user_id = u.user_id
group by
    user_id,
    user_name
order by
    total_points desc

Answer 3

典型的设计是使用User表，Action表和User_Action表来记录用户完成的所有操作。你需要两个外键，可能还有一个主键，以及完成它时的日期戳。然后，您可以将每个操作的点存储在Action表中，并且每当您查找总点数时，只需加入表格并按时间戳排序，这样您就可以获得其点数的历史记录。

Answer 4

如果您确实希望能够将操作追溯到商店或答案表中的某一行，请添加第四列，这是该行动添加的行的pk条目。

数据库设计 - 为用户存储点的方法

4 个答案: