mysql - Rails数据库结构及优化建议

Question

我的 Rails 应用程序是一个用户在彼此之间交易项目的系统。用户对元素出价，然后所有者批准创建交易的出价。然后，用户可以在交易上写评论(消息)以在应用程序之外组织事物。到目前为止，我的结构是这样的:

User
    has_many :items
    has_many :bids

Item 
    belongs_to :user
    has_many :bids

Bid
    belongs_to :item
    belongs_to :user
    has_one :transaction

Transaction
    belongs_to :bid
    has_many :messages

Message
    belongs_to :transaction
    belongs_to :from, :class_name => "User"
    belongs_to :to, :class_name => "User"

我认为这在减少冗余方面效果很好，但我在高效获取数据方面遇到了一些问题。例如，要检索用户的“给定元素”(即其中一个出价存在交易的用户元素)我正在做:

user.items.joins(:bids).where("bids.id" => Transaction.select("bid_id"))

或收到的元素:

Item.joins(:bids).where("bids.user_id" => user.id).where("bids.id" => Transaction.select("bid_id"))

对于我想要的信息来说，这似乎是相当昂贵的。

更重要的是，我想汇总用户的交易并显示赠送元素与收到元素的比率，这可能会显示在任何给定页面上的用户名旁边。目前，我正在做的是获取并计算上面所有用户提供和接收的项目，然后进行划分(这非常昂贵......)。我正在考虑在 User 表上有一个包含 received_count 和 given_count 的列，每次创建或销毁事务时都会更新，但这似乎不可靠。

我的问题是，是否有更好的方法来构建我的数据，以便更简单地获取用户交易等信息，同时保持其规范化？

谢谢!

Answer 1

通常规范化和性能是权衡的。在您的情况下，我认为将额外的列添加到 Users 表以有效缓存结果是有意义的。您还可以向项目添加一个额外的列，以显示它们是否对交易进行了出价。

归一化确实是一个基本原则，而不是你应该为了正确性而坚持的东西，缓存常用结果，即使它会产生冗余也是一个非常好的方法。

唯一的其他选择是实际使用缓存(例如 memcached)。这将使您可以将计数存储在实际缓存中，并在该用户发生新交易时“破坏”它们。