|
锁定老帖子 主题：不知道是不是该用vo，或者说该怎么用vo
精华帖 (0) :: 良好帖 (5) :: 新手帖 (3) :: 隐藏帖 (16)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-08-30
nishizhutou 写道 IcedCoffee 写道 d-jasonlee 写道 这个粉丝数我想是通过sql count出来的，但是User这个PO里没有这个属性 你的user不是多对多的吗？ 那么user里面应该有个List<User> fans来保存用户. 然后fans.size()就知道个数了.. 你不能只是为查个总数,就要把每个数据都取出来吧.... 而且说实话,像围脖这样的应用,交叉数据及其多,我觉得还是纯jdbc来的好.任何orm工具最后都是瓶颈. 说的对..如果要做还是用jdbc最好.. |
| 返回顶楼 | |
|
发表时间：2010-08-30
注意一件事：性能和设计有的时候是对立的。
设计的很清晰，很多时候造成性能会很差。所以才有架构设计是双刃剑一说。 如果是我，只单纯统计人数的话，我会毫不犹豫的增加冗余字段。 |
| 返回顶楼 | |
|
发表时间：2010-08-30
个人认为,在非增删改为主,或业务逻辑非主导因素的系统中,是否将关系映射成对象是个很值得斟酌的问题.
因为页面显示往往都是关系型的.orm的作用无非就是方便业务的操作,以及使架构更清晰.但是会造成性能损耗. lz的系统既然都提到多用户了,那么性能应该是主要考虑的因素,个人觉得不一定要有orm. |
| 返回顶楼 | |
|
发表时间：2010-08-30
giginet 写道 注意一件事：性能和设计有的时候是对立的。
设计的很清晰，很多时候造成性能会很差。所以才有架构设计是双刃剑一说。 这句话说的好啊，嘿嘿，多谢指点。 yangxinxyx 写道 ibatis的result不要和VO混成一谈，ＶＯ是面对页面展示层，如果ibatis的result就直接返回的是Vo,那么项目就很难扯清了。。
就这个问题今天上午我与同事讨论了，他的意思是直接返回vo，被我坚决反对了。我可以返回带有对象关系的po，如果愿意可以在service里去转换vo吧。其实他们所谓的vo就是将po里的对象关系都取消了，需要的字段都定义为vo类的属性…… nishizhutou 写道 相比起显示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%的用户的某个信息. 您解释的非常到位！非常感谢！ javaeye的氛围的确很好，多谢上面几位牛人，小鸟在此谢过了。 |
| 返回顶楼 | |
|
发表时间：2010-08-30
count应该设计为冗余字段，要不性能肯定撑不住。对于sns，其实还应该考虑分表，如按照用户把数据分开存放，要不数据量上去以后系统会慢个半死。
|
| 返回顶楼 | |
|
发表时间：2010-08-31
还没学ibatis
|
| 返回顶楼 | |
|
发表时间：2010-09-12
myreligion 写道 count应该设计为冗余字段，要不性能肯定撑不住。对于sns，其实还应该考虑分表，如按照用户把数据分开存放，要不数据量上去以后系统会慢个半死。
先做出来，等用户量上去后，真的系统慢了，再去优化，建议不要过度设计 |
| 返回顶楼 | |
|
发表时间：2010-09-15
nishizhutou 写道 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%的用户的某个信息. 这位兄弟说的有道理，系统往往是慢慢发展起来的，你可以在当前的系统用户量、访问量和系统承受能力中做一个折中的选择，但必须得时刻保持一定的前瞻性，至少要保证项目在3个月内都是可以正常支撑现有的增长速度的，那么你这个项目从总体上来说还是很不错的 |
| 返回顶楼 | |
