锁定老帖子 主题:一次小项目的思考
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-08-21
最后修改:2009-08-21
存储方案不用数据库用什么,难道自己开发?
世界上有几个Google呢? 就算自己开发,你确认各方面都比现有方案好? 财力,才力 |
|
返回顶楼 | |
发表时间:2009-08-21
暂时还没有这方面的经验,看不懂再说什么
|
|
返回顶楼 | |
发表时间:2009-08-21
好像大家对Hibernate成见很深,其实无非就是性能问题。
自己说几点心得: 考虑使用Hibernate一定要考虑本身的数据库建模适合不适合,我之前做项目数据库建模建的很差,那种情况下使用Hibernate很别扭。 如果从业务逻辑上A依赖B,B又依赖C,C又依赖D,这个不一定就一定要把A、B、C、D揉在一起搞,这么搞,哪个ORM都受不了,尝试着去分成若干的小块就搞。 大型系统一般都会搞集群,这样的话我们就仅考虑单点的性能了。经常有人说,我有上亿数据,用Hibernate怎么搞。如果一个单点搞定比较难了,你直接使用JDBC一样很难搞定。 反正怎么说呢,天下没有免费的午餐。想用好Hibernate,如果不深入,那么很难用好的。再说一下,Hibernate也不是银弹。 |
|
返回顶楼 | |
发表时间:2009-08-21
everlasting_188 写道 好奇怪的想法:
1>无论使用什么技术,持久化现在的解决方案都是数据库,如果你能提出自己使用hiberante+自己的持久存储(比如自己写数据库)来解决的话,那是超级大牛 2>如果自己做不了持久存储,使用数据库的话,那: 凭什么说以数据库设计,结合ORM有问题。进一步说,你使用hibernate+文件存储(自己定制hiberante的sql的引擎)也能行,但是你的解决方案有多大价值。 你使用hibernate加上自己的设计,可以解决水平的问题,单是单点性能的问题你如何解决?绝大多说在百万级的数据下(并发<100),不需要考虑水平扩展,恰当的使用数据库,单台机器就解决了,而你只是觉得ORM是外能,根本不考虑充分利用数据库性能,用了10台机器,对客户来说会使用谁的方案。 3>终极的方案是:定制自己的存储和分布数据策略,和使用hiberante没什么关系,只是一种工具。 淘宝没有用hiberante,仍然做的很好。 每一种技术都有适当的范围,不是万能的钥匙。 同意一下.呵。。。 |
|
返回顶楼 | |
发表时间:2009-08-21
小型项目可以,大型项目就别想了。
一般大型的企业应用都是由资深业务人员(这些人只注重业务,不注重技术)定的数据库结构,开发根本主导不了。这就是国内的现状。 |
|
返回顶楼 | |
发表时间:2009-08-21
确实,小项目可以。大点的项目我还是更愿意看E-R图和表结构,所谓蜘蛛网的E-R图也应该会有局部的切分。总之,lz的想法不错。
|
|
返回顶楼 | |
发表时间:2009-08-21
最后修改:2009-08-21
jdon我以前也去过不少次,那个板桥就是“数据库已死”的坚决鼓吹者。个人认为这种思想太极端。
无论是orm,还是存储过程,都不会这么轻易的死掉。各有各自适合的场景。 |
|
返回顶楼 | |
发表时间:2009-08-21
这些东西,不同的公司侧重点是不一样的
|
|
返回顶楼 | |
发表时间:2009-08-21
everlasting_188 写道 百度的开发经理说过一句话:如果你的程序能让Cpu和IO同时达到95%以上,google和百度肯定会录用你。 你这不也是人云亦云,什么程序在没有负载的情况下能让cpu和io同时达到95%,那开发者也真是"牛人"了,太会利用资源了。 而在有高负载的情况下,还有什么程序不能让cpu和io同时达到95% ? 所以这个所谓的百度开发经理说的就是一句废话! |
|
返回顶楼 | |
发表时间:2009-08-21
数据库设计相当重要啊,项目到了后期就体现出来啦
|
|
返回顶楼 | |