Rails 问一个 ruby-china 的 notification 的效率问题
现在 ruby-china 的通知是一个单独的表，和用户做关联，基于通知多样性的原因用了一个叫做 Notification::Base 的基类，
class Notification::Base
include Mongoid::Document
include Mongoid::Timestamps::Created
include Mongoid::BaseModel
# ...
belongs_to :user
# ...
end
另外一种比较常见的处理方法是 embed 在 user 里，后者的查询时间是 O(1) 的，前者会随着表的增大速度变慢，ruby-china 有否考虑过这点，有考虑 ? 如何考虑的 : 考虑一下吧。 @huacnlee
不懂 mongodb，弱弱问一句，按照这个理论，所有和 user 关联的表都可以 embed 到 user 表里面，然后查询时间都 O（1）了。这样理解对吗
@hooopo embed 的东西关联性很弱，因为是不成表直接存在 document 里的，所以不能直接找到，必须先找到 User 才能找到 Notification（如果 embed），所以 has_many :notifications 这种东西就不能直接写了，所以不可能都 embed 进来的。如果确定是比较单一的联系，比如评论几乎只和新闻相关，于是 embed 在新闻里，是非常合适的。
@xranthoar ruby-china 的 notification 都是只有一个接收者，所以可以把 read 写到 notification model 里，咱们的是多接收者的，如果也把 read 写到 notification model 的话，就相当于是一个多对多的关系，这样每次获取某个用户的所有通知时，判断是否已读的代价会不会很高（通知接收者可能很多）？
embed 在 User 里面 user object 就会变大，试想这个帖子页面为了显示每个回帖用户都把他的消息都载入进来。为了避免无关的地方载入了消息，又要把所有查询 except 掉 notification……考虑到读消息是少数操作，所以应该分离出去。
有个可以优化的地方是把 unread_notification_count 加到 User 里面。
