项目规模不大的话，数据库直接 join 什么其实还是很好用的。
瞅了一眼楼上为什么好多不推荐 join 的感觉都没说到点上。

我自己的经验就是：
1.大项目需要分表分库，join 在分库分表的情况下处理起来很麻烦。
2.缓存问题。比如某个订单列表里包含有用户昵称，这个昵称因为是通过 join 查询因此也被缓存起来了，假如某个用户改了昵称，那么很容易会忽略掉这些缓存造成不一致的问题。
3.用业务代码替代数据库 join ，也能方便日后服务化。比如用户系统和订单系统以后做拆分了，vo 需要同时展示订单信息+用户信息，那么就可以根据关联的 id 调用其他服务来获取数据，减少重构成本。（ UserDAO.findById -> UserRemoteService->findById ）
4.一般情况下，join 是不会直接 select *所有字段的，一般都是按需选字段。不同的业务需要取不同字段的话就要写不同的 join 了，还不如直接 id 直查关联数据，按需选取。

至于你说的多表关联，一般是要求不超过三张表 join 的。
像商品-订单-用户，就是典型的用户-商品多对多关系，订单可以看作是关联表并且额外维护了其他的信息。
但是像角色-角色权限关联表-权限，也是一个多对多关系，但是由于角色-权限本身是紧密耦合的，不会像商品用户那样可以独立作为一个系统，他们的关联表也不需要维护额外的信息，所以这种场景肯定还是 join 更合适。