在用户数据库中包含帐户信息

发布于 2024-08-19 04:37:26 字数 240 浏览 7 评论 0原文

我正在构建我的第一个 Rail 应用程序,并开始设置我的数据库。我有一个简单的用户表,其中包含姓名、电子邮件(登录名)、密码等。

该网站允许用户互相打赌(用垄断资金),因此我需要将有关用户当前奖金和其他微妙事项的信息添加到数据库中。

问题:我应该将这些信息放入用户表中,还是应该创建一个帐户表并在其中插入信息。我缺乏知识来了解在用户表中插入信息是否会引发任何安全问题。

亲切的问候

肯尼斯
丹麦

I'm building my first Rail App and are beginning to setup my database. I have a simpel Users table containg name, e-mail (login), password and so on.

The site lets the users bet each other (with monopoly money), so I need to add information about the users current winnings and other delicate matters to the database.

Question: Should I place these information in the Users table or should I create an Account Table and insert the information there. I'm lacking the knowledge to see if it should raise any security issues to insert the information in the Users table.

Kind regards

Kenneth
Denmark

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

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

发布评论

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

评论(2

风和你 2024-08-26 04:37:27

从事务的角度来看,拥有跟踪操作的辅助记录比修改单个记录要好得多。

例如,如果您有一个用户可以下“赌注”的系统,那么理所当然地会有某种 Bet 类来定义两个人之间的赌注。随着用户下注,相关列表将会增长。用 Rails 的说法,它看起来像这样:

class User < ActiveRecord::Base
  has_many :bets
  has_many :bet_pools,
    :through => :bets
end

class Bet < ActiveRecord::Base
  belongs_to :user
  belongs_to :bet_pool
end

class BetPool < ActiveRecord::Base
  has_many :bets
  belongs_to :winning_bet
  belongs_to :winning_user,
    :class_name => 'User',
    :through :winning_bet,
    :source => :user
end

每次下注的金额存储在下注记录中,而 BetPool 代表针对特定下注的总下注,尽管您可能对此类事物有不同的术语。

如果投注结算时,可以通过分配 bet_pool.winning_user 关联来指定获胜者。

如果你想知道某个用户的“中奖记录”,那么只需将他们所中奖的所有投注池列表并将金额相加即可。

您不想不断调整用户记录上的某些属性的原因是因为两个独立的进程可能想要调整该值,并且如果 SQL 未正确实现,您最终可能会遇到竞争条件。例如,用户可能下注并在很短的时间内赢得赌注。

如果用户以 1000 美元开始,并且同时发生两个操作,则可能会发生这种情况:

# Process A intending to add $500
user.balance = user.balance + 500
user.save

# Process B intending to deduct $100
user.balance = user.balance - 100
user.save

按顺序完成,您预计余额会从 1000 到 1500,然后下降到 1400,但第二个过程以原始值 1000 开始,当加载,然后调整为 900 并保存,覆盖第一个结果。

ActiveRecord 的 增量 和减量等方法可以帮助解决此类问题,但最好的结果是通过简单地根据需要进行制表来实现的。

From a transactional point of view, it is much better to have subsidiary records that track operations than to modify a single record in place.

For instance, if you are having a system where users can place "bets", then it stands to reason there would be some kind of Bet class that defines a bet between two people. As users create bets, the associated list will grow. In Rails parlance, it looks like this:

class User < ActiveRecord::Base
  has_many :bets
  has_many :bet_pools,
    :through => :bets
end

class Bet < ActiveRecord::Base
  belongs_to :user
  belongs_to :bet_pool
end

class BetPool < ActiveRecord::Base
  has_many :bets
  belongs_to :winning_bet
  belongs_to :winning_user,
    :class_name => 'User',
    :through :winning_bet,
    :source => :user
end

The amount of each bet is stored in the Bet record, and the BetPool represents the aggregate bets made towards a particular wager, though you may have a different term for such a thing.

A winner can be designated by assigning the bet_pool.winning_user association if and when the bets are settled.

If you want to know a user's "winning record", then it is as easy as tabulating all the betting pools that they've won and adding up the amounts.

The reason you don't want to be constantly adjusting some property on the User record is because two independent processes may want to tweak that value and you can end up with a race condition if the SQL is not implemented properly. For instance, a user might place a bet and win a bet in a very short period of time.

If a user started with $1000 and two operations occur simultaneously, then this could happen:

# Process A intending to add $500
user.balance = user.balance + 500
user.save

# Process B intending to deduct $100
user.balance = user.balance - 100
user.save

Done sequentially you'd expect the balance to go from 1000 to 1500 and then down to 1400, but the second process started with the original value of 1000 when it loaded, then adjusted to 900 and saved, over-writing the result of the first.

There are methods like increment and decrement for ActiveRecord that can help with this sort of thing, but the best results are achieved by simply tabulating as required.

分开我的手 2024-08-26 04:37:26

他们的行为与实际用户本身是不同的实体。将个人资料信息等用户信息保存在一张表中。所有其他实体应分开。因此,您希望将其分离到另一个表中,并创建一个回到用户表的外键,以确定该帐户表中的哪一行属于该用户。

Their actions are a different entity then the actual user themself. Keep user information such as profile info in one table. All other entities should be seperated. So you want to seperate that into another table and create a foreign key back to the users table to determine which row in this accounts table belongs to the user.

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