join 太多自己都觉得麻烦，不过对于这种一个 associate 表，专门负责各个 index 关联的，除了 join ，再就是分解成子查询了，还有其他方法么？我也很想知道。
#r13 @
jarlyyn 你们是一条记录主键，关联这么多表的各条记录的 id ，这样实现的吧。
我有一个问题是，如果要对这一条记录进行操作，是不是要分解为多个子查询？
举个例子，我有一个功能是显示用户的累计消费金额。如果用户对一个订单的某个商品进行了退款操作，我要更新用户的累计消费金额，就得在退款的同时，更新这个关联表，然后通过关联表，查询对应的用户 id ，更新用户的累计消费金额。很麻烦，但是感觉也没有其他很好的办法。你们是怎么做的？
还有就是这个累计金额，你们是在用户表里面单独定义了一个字段，还是每次都重新查表计算生成？我们是单独定义了一个字段，因为这个累计金额会很频繁的用到，比如用户登录之后提示，用户每次打开用户信息页面等等，每次都通过查询计算生成的话，感觉会占很大的开销。但是这样做的话，可能会有字段存储的值与实际值不一致的潜在风险，比如用户退货的时候需要更新这个字段，用户在降价之后申请价格保护也会更新这个字段，用户下新的订单会增加这个字段，我们现在是封装了一个函数，业务完成后自动 update ，目前业务逻辑梳理的还算是比较清晰，没有出过问题。但是如果以后有新手接手，忘记添加这一个操作，就有可能造成不匹配，所以一直想问问同行这种情况到底怎么处理算是 best practice 。