只是一个快乐。我正在开发网站,您可以在网站上购买积分并将其用于网站上。 我的问题是,用户(用户表,列信用额和迭代金额)存储信用额度是否可以,或者有必要(或者更好)拥有用户ID和金额的单独表格?
由于
答案 0 :(得分:5)
实际上都是。
考虑到您将处理货币交易以获得这些信用,您希望能够获得所有交易的日志(根据您所在国家/地区的法律,您将需要此信息)。因此,您需要一个credits_transactions
表。
user_id, transaction_id, transaction_details, transaction_delta
由于以编程方式计算当前的信用余额对于拥有大量交易的用户来说成本太高,因此您还需要在用户表中添加credit_balance
行以便快速访问。每当从credits_transactions
插入行时,使用触发器自动更新该列(从技术上讲,该表中不允许update
和delete
)。这是插入触发器的代码。
CREATE TRIGGER ct_insert
AFTER INSERT ON credits_transactions
BEGIN
UPDATE users SET credit_balance = credit_balance + NEW.transaction_delta WHERE user_id = NEW.user_id;
END
;;
答案 1 :(得分:2)
我还有包含信用的网站,并且最容易将它们存储在用户表中,主要是因为您需要在每个页面上访问它(当用户登录时)。它只是一个整数,所以不会造成太大的伤害。我认为实际上为这个值创建一个新表可能会更糟糕,因为它需要一个索引aswel。
一个好的经验法则是为每个页面上所需的信息创建一个用户表,并规范化每个页面上不需要的数据(例如地址信息,描述等)。
编辑: 看到其他反应,
如果你想要交易日志aswel我会单独存储它们,因为它们主要用于记录(或者如果用户想要查看它们)。从日志中动态计算它们对于较小的站点来说很好,但如果你真的必须挤压性能,只需将实际值存储在用户表中。
答案 2 :(得分:1)
如果您存储在单独的表中,您可以保留更改信用的日志。如果您存储在列中,则只有当前的信用额度。
答案 3 :(得分:1)
如果您想保留Credits History Log的记录,如
我认为最好把它放在一个单独的表中。通过这种方式,您可以通过应用数学运算来获得这些结果。
答案 4 :(得分:1)
积分就像金钱。如果用户需要购买,那么就是金钱。使用帐户跟踪资金。帐户已关联交易,存款和提款 - 以及余额。搜索SO或谷歌搜索数据库和帐户。以下是几个例子:
答案 5 :(得分:0)
我有一张表存储购买和购买的积分,用户ID。 然后基于此计算每次,如果它被索引,它应该很快,这样你就可以轻松获得购买历史。