职业IT人-IT人生活圈

 找回密码
 成为会员
搜索
查看: 1029|回复: 9

不知道是不是该用vo,或者说该怎么用vo

[复制链接]
broken 发表于 2011-9-2 11:39 | 显示全部楼层 |阅读模式
最近在实现一个微博,遇到了很多大小问题,下面是其中一个问题:

用户与用户之间可以加好友,但是好友可以是单向的,如果a将b加为好友,那么a就是b的粉丝。反过来也一样。
我在设计数据库的时候,建了个user与user的多对多关系表。

在页面上,浏览用户好友列表的时候,可以显示出该用户每个好友的粉丝数,也就是有多少人加了这个人为好友。
这个粉丝数我想是通过sql count出来的,但是User这个PO里没有这个属性。于是有个小问题:

是否该建个 vo,作为dao查询结果返回?我用的是ibatis,那么resultClass就成了这个vo了,这样做好吗?

我现在的做法,是建了个VO,ibatis的resultClass设置为vo,sql中使用子查询。

  
public class Friend {   
    private Long userId;   
    private String nickname;   
    private String address;   
    private Integer fans;   
        //getters and setters...   
}  

public class Friend {
        private Long userId;
        private String nickname;
        private String address;
        private Integer fans;
        //getters and setters...
}


Xml代码  
<!-- 查询用户所有好友,返回VO -->  
<select id="findByUserId" parameterClass="Long" resultClass="vo.Friend">  
    <![CDATA[  
        select  
            fu.user_id as `userId`,  
            fu.nickname as `nickname`,  
            p.residence_id as `address`,  
            (select count(*) from friend where friend_id=fu.user_id) as `fans`  
        from  
            friend as f  
            inner join user as fu on fu.user_id=f.friend_id  
            left join profile as p on p.user_id=f.friend_id  
        where  
            f.user_id=#value#  
    ]]>  
</select>  

        <!-- 查询用户所有好友,返回VO -->
        <select id="findByUserId" parameterClass="Long" resultClass="vo.Friend">
                <![CDATA[
                        select
                                fu.user_id as `userId`,
                                fu.nickname as `nickname`,
                                p.residence_id as `address`,
                                (select count(*) from friend where friend_id=fu.user_id) as `fans`
                        from
                                friend as f
                                inner join user as fu on fu.user_id=f.friend_id
                                left join profile as p on p.user_id=f.friend_id
                        where
                                f.user_id=#value#
                ]]>
        </select>


本人还是个小菜鸟,java工作才1年出头,请大侠们多指点,万分感激!

走就走吧 发表于 2011-9-2 11:39 | 显示全部楼层
你这个帖子估计很快就要被JE和谐掉。

回答问题,我也是新手,但是我面对这种情况,毫不犹豫,给你所谓的po增加个count属性。
要不你就返回一个hashmap(不推荐)。

已经来了吗 发表于 2011-9-2 11:39 | 显示全部楼层
每个登录到自己首页的人,他的好友数都是count出来的? 这样不太好吧.你们预计的规模能有多少?有没有评估过这个查询的数量级?毕竟这个数据会常显示,至少一次登陆就给查一下.是不是可以考虑冗余一下这个字段?

yoyo 发表于 2011-9-2 11:39 | 显示全部楼层
hilliate 写道
你这个帖子估计很快就要被JE和谐掉。

回答问题,我也是新手,但是我面对这种情况,毫不犹豫,给你所谓的po增加个count属性。
要不你就返回一个hashmap(不推荐)。


问题很菜,见笑了!
你的意思是说在用户表中加入一个字段(例如叫count)来标记他被多少人关注?
这样就是有人在关注他的时候update一下这个用户的这个字段,有人解除关注的时候也update一下这个用户的这个字段。

不知我这么理解对吗?

只学java 发表于 2011-9-2 11:40 | 显示全部楼层
JE帐号 写道
每个登录到自己首页的人,他的好友数都是count出来的? 这样不太好吧.你们预计的规模能有多少?有没有评估过这个查询的数量级?毕竟这个数据会常显示,至少一次登陆就给查一下.是不是可以考虑冗余一下这个字段?


非常感谢,我没有过成熟项目的经验,呵呵,确实应该冗余一下。

jinchang 发表于 2011-9-2 11:40 | 显示全部楼层
d-jasonlee 写道
hilliate 写道
你这个帖子估计很快就要被JE和谐掉。

回答问题,我也是新手,但是我面对这种情况,毫不犹豫,给你所谓的po增加个count属性。
要不你就返回一个hashmap(不推荐)。


问题很菜,见笑了!
你的意思是说在用户表中加入一个字段(例如叫count)来标记他被多少人关注?
这样就是有人在关注他的时候update一下这个用户的这个字段,有人解除关注的时候也update一下这个用户的这个字段。

不知我这么理解对吗?

太耗数据库资源了

醉倚西风 发表于 2011-9-2 11:40 | 显示全部楼层
d-jasonlee 写道

这个粉丝数我想是通过sql count出来的,但是User这个PO里没有这个属性



你的user不是多对多的吗?
那么user里面应该有个List<User> fans来保存用户.
然后fans.size()就知道个数了..

jinchang 发表于 2011-9-2 11:40 | 显示全部楼层
ibatis的result不要和VO混成一谈,VO是面对页面展示层,如果ibatis的result就直接返回的是Vo,那么项目就很难扯清了。。

天上智喜 发表于 2011-9-2 11:40 | 显示全部楼层
yuantong 写道
d-jasonlee 写道
hilliate 写道
你这个帖子估计很快就要被JE和谐掉。

回答问题,我也是新手,但是我面对这种情况,毫不犹豫,给你所谓的po增加个count属性。
要不你就返回一个hashmap(不推荐)。


问题很菜,见笑了!
你的意思是说在用户表中加入一个字段(例如叫count)来标记他被多少人关注?
这样就是有人在关注他的时候update一下这个用户的这个字段,有人解除关注的时候也update一下这个用户的这个字段。

不知我这么理解对吗?

太耗数据库资源了


相比起显示count的次数来讲,我想关注和取消关注的次数应该是少好几个数量级的.
比如说,这个产品在1个月能有1万个用户,平均每个用户关注50人(这个平均关注度已经很高了吧).那么在这一个月中,需要50万次update操作.假如仅在登录首页的时候要显示count(这应该非常少了吧?事实上可能会很多地方都显示).按每个人每天进入首页1.5次.那么也给查询45万次.(要注意的是,当用户很多的时候,这个查询的系统消耗非常恐怖).
最重要的是,当你去关注某人的时候,你还会看到对方的count的.所以每一次的update都意味着至少两次的查询(查询对方,和刷新后显示自己的,这还不包括大家串门时到别人首页时看到的别人的count).


所以说,count的query和count的update次数差一百倍绝对不为过.

我还是建议冗余count这个字段.只要注意update的时候行锁定而不是表锁定就行.

至于为什么不去用应用缓存,而是要采用数据库字段冗余,这是因为count只是一个字段.应用级别的缓存,最好还是缓存一个业务单元.count有点过小了.比如说,经过分析,你发现这个服务中,30-50% %的请求都只是针对5%的用户的信息进行请求的,此时你就需要去缓存这5%的用户的完整信息.而不是很广义的去缓存100%的用户的某个信息.




feiguo 发表于 2011-9-2 11:40 | 显示全部楼层
IcedCoffee 写道
d-jasonlee 写道

这个粉丝数我想是通过sql count出来的,但是User这个PO里没有这个属性



你的user不是多对多的吗?
那么user里面应该有个List<User> fans来保存用户.
然后fans.size()就知道个数了..


你不能只是为查个总数,就要把每个数据都取出来吧....

而且说实话,像围脖这样的应用,交叉数据及其多,我觉得还是纯jdbc来的好.任何orm工具最后都是瓶颈.
您需要登录后才可以回帖 登录 | 成为会员

本版积分规则

QQ|手机版|小黑屋|网站帮助|职业IT人-IT人生活圈 ( 粤ICP备12053935号-1 )|网站地图
本站文章版权归原发布者及原出处所有。内容为作者个人观点,并不代表本站赞同其观点和对其真实性负责,本站只提供参考并不构成任何投资及应用建议。本站是信息平台,网站上部分文章为转载,并不用于任何商业目的,我们已经尽可能的对作者和来源进行了通告,但是能力有限或疏忽造成漏登,请及时联系我们,我们将根据著作权人的要求立即更正或者删除有关内容。

GMT+8, 2024-5-5 18:04 , Processed in 0.108072 second(s), 20 queries , Gzip On.

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表