1 2 3
►
Go
总共有 44 回复 ／ 3 页
|
|
|
|
|
|
|
JDON是个不错的论坛，在里面可以学到很多东西，尤其是设计模式，面向对象的很多知识，不过有一点非常太赞同，就是BAND，喜欢弱化数据库，面向对象和数据库都是现在软件开发中的工具，谁也不能替代谁，BAND可能是理论派的，没有在大型公司做过太多的实际项目，殊不知，现在大型系统尤其是象ERP，电信方面的系统主要还是数据处理，数据量非常庞大，动辄几千万，查询关联的表动辄几十个，如果还纯粹的面向对象，性能问题就足以把项目催垮，以至于现在大公司里必然有很多DBA，来做这方面的工作，数据库也尤为重要。数据库的性能优势是面向对象无法比拟的。你看EBAY，阿里巴巴，newegg等一些世界大公司，都是以数据处理为中心。
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 00:20
|
|
|
db是存贮工具。性能可用缓存解决
不过我也很无奈，我得听别人的安排放弃一些东西
[该贴被freebox于2008-08-12 00:22修改过]
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 06:46
|
|
|
大型企业级开发数据量都是巨大的，性能会有瓶颈，不太可能把所有数据都缓存吧，这就得靠数据库性能优化来解决了，我是学面向对象出身的，刚开始也是像freebox 这样认为的，但是几年在大型企业的经历以后，发现
数据库方面才是非常重要的。
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 07:29
|
|
|
其实要求的数据不一定都在一个主机上。数据中心也不一定就是数据库中心，数据可以用对象体现出来。
我觉得如果数据量大的话，对象缓存处理不了，数据库也同样处理不了。如果数据库能处理，我认为缓存也能处理。
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 08:53
|
|
|
|
现在大型应用数据量一定是很大的，通过数据库很好做性能优化。
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 08:59
|
|
|
|
数据库里的数据至少都是几百G，不可能全部缓存在内存吧。数据库优化强调，正确设计表，如何建索引，如何写SQL，这些可以很好的优化。当然面向对象在架构设计也是很重要，不过两者是互补的。
|
|
|
|
|
|
回复:跟BANG老师探讨下
|
2008年08月12日 13:06
|
|
|
表面上看数据量大，但他们都是业务数据，我们可以通过Evans DDD来将复杂大量数据进行监化模块化，而某段时间中业务数据访问比较集中，这段业务数据使用业务对象缓存效率高。
你试图找一个通用解决方案来统一解决这些大数据量问题，显得很外行和幼稚，而且也没有深刻体会面向对象的真谛：具体问题具体分析，具体解剖。这些都是现实生活中通用哲学方法，怎么会都没有掌握呢？
>数据库也尤为重要。数据库的性能优势是面向对象无法比拟的。你看EBAY，阿里巴巴，newegg等一些世界大公司，都是以数据处理为中心。
这是落伍的认识，那你看看google是否以数据处理中心？这是一云计算为中心：云计算是方向，云计算必然淘汰数据中心，云计算就是弱化数据库：
http://www.jdon.com/artichect/architecture.html
[该贴被banq于2008-08-12 13:18修改过]
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 13:33
|
|
|
|
那请问下，如果象汇总、统计等之类的怎么用面向对象的方式实现。在数据库里可以用sum,count,rownumber之类的。
|
|
|
|
|
|
回复:re:跟BANG老师探讨下
|
2008年08月12日 13:54
|
|
|
>汇总、统计等之类的怎么用面向对象的方式实现,在数据库里可以用sum,count,rownumber之类的。
汇总 统计就是对你的业务对象进行汇总和统计了，听到这个答案，你可能觉得象白说，因为你脑子里都是数据库的影子，总是以为不是sum/count/rownumber，也是另外一种dum/xxx/heloornumber之类语法来解决吧。
告诉你，根本不是，oo没有数学公式，没有定理，没有SQL这样的标准语法，Java就是语法，模式就是定理，具体问题具体分析就是解决方式。
回过头来再看看：汇总就是对一一段时期内业务对象的计算，至于这些业务对象是从哪里来，我不关心，有可能来自数据库（那么就等效于你的sum/count之类语法）；有可能来自另外一台服务器或B2B或SOA的来源（这个你就不能用sum语法来对付吧）。
下面的问题，我知道你又要开始比较他们的性能了，但是，且慢，用OO方面我都没有给你具体语法，你如何比较呢？我这里重点指出了思考方式的不同。但是话说回来，如果业务对象来自数据库，我也可以利用数据库的一些优化技巧，但是这些都不是重点，重点是，我关注重点是活在内存 分布在多台服务器内存中的业务对象，而不是后台数据库中僵死数据，而且通过云计算和集群，这些活着的对象7/24几乎无需睡眠（持久保存数据库），就象著名社交网站LinkedIn的Java架构技术指出一样：从硬盘重建内存Cloud一个实例需要8个小时（能频繁开关机吗？必须7/24一直运行）。
http://www.jdon.com/article/34214.html
[该贴被banq于2008-08-12 14:12修改过]
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 16:19
|
|
|
|
OO的优势在于业务处理，数据库的优势在数据运算，我在大型企业做ERP的时候曾经编写过MRP算法，需要计算库存，计划，合同，送货单，计算逻辑非常复杂，又是汇总，又是合并，这种用OO的方法是没有办法实现的。我想说的是，不管是OO，还是数据库都只是一种工具而已，任何走极端的都是错的。数据库的很多高级特性是面向对象所无法比拟的。要不然为什么那么多世界级的大公司，都有那么多的DBA呢。
|
|
|
|
|
|
回复:re:跟BANG老师探讨下
|
2008年08月12日 17:08
|
|
|
>我在大型企业做ERP的时候曾经编写过MRP算法，需要计算库存，计划，合同，送货单，计算逻辑非常复杂，又是汇总，又是合并，这种用OO的方法是没有办法实现的
不能这么绝对武断，计算逻辑算法复杂，更要采取OO进行分离，比如引入策略模式等等，OO方法是一种方法论，不能当饭吃，也就是说方法论和算法是两个不同东西，算法只是具体实现的一种手段，而OO方法论重要性要高于算法等具体科学。
其实你就是数据库思维，所以，OO和DB争论国外至今一直进行，不是三言两语能够辩完。
倡导OO，就是我们所有计算汇总合并基准数据是对象，而不是直接基于数据库数据，我想这是我要表达的。因为如果你直接使用SQL基于数据库数据计算，那么数据库服务器负载就会很重，你只有增加单机性能才能提高其应付处理复杂的逻辑，但是如果我们将这种计算负载移植到中间weblogic/websphere/jboss这样应用服务器上，通过增加服务器个数就能成倍提高处理性能，到底哪个性价比更高呢？而且没有单机单点风险。
你所说的eBay其实也遵循这个思路，他们的架构师曾经参与J2EE核心模式的起草，这个核心模式中不少就是EJB或分布式计算的。
90年代，一个DBA年薪20万，而如今一个JavaEE架构师年薪几十万，说明，如今IT热门已经发生转移，使用OO新技术架构起来的系统，将更加依赖架构师，而不是DBA，DBA只能维护那些老的DB系统，Oracle DB老大已经重点转移JavaEE，是第一个推出EJB3服务器的厂商，老大都闪了，何必那么死心眼揪住数据库呢，那只是10年前的事情了。
说了这么多，你可能还是认为我是理论派，我举个现实例子：
最近几个老外基于Spring+Hibernate架构的Appfuse整出一个自动分页排序的软件pagingappfuse，它后台是基于Compass//Lucenc全文检索，注意不是关系数据库，可以实现进行任何列表字段（注意是界面列表）的大小排列，它的表现层列表变换是采取Display Tag，
http://www.nabble.com/Appfuse-searching-with-Compass-2.0-(Lucene)-td17368089s2369.html
试验想想：你那些基于SQl的复杂合并汇总，如何能够移植到Compass/Lucene这样新的持久层检索技术上？恐怕必须重新写，而基于对象的复杂计算则不必关系数据来源于DB还是Lucene。。。。。，既然DB的东西要延展生命必须重写，那就表明它的时代已经彻底结束。
[该贴被banq于2008-08-12 17:24修改过]
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 23:06
|
|
|
1。数据库也可以集群。
2。这里所说的算法不光是指冒泡算法之类的算法，更是指企业级的数据运算。比如说像MRP里面的计算，根据
各种各样的库存，采购计划、采购指令、合同、送货单（很多种）、送货指令（很多种）来计算，包括像汇总、排序、计算等等。针对这种大型企业计算，数据库为我们提供了很多经过数据库内核优化了的函数，像rank,row_Number,sum之类的，如果这种我们自己用OO写算法实现，我不敢想想。对于这种复杂运算我们通常是让数据库在夜间自动运算几个小时来实现，如果用OO，实现起来的效率何在。目前好像还没有谁用OO来做这种MRP的运算吧。
3.我是赞成用缓存的，但是难道要把数据库里所有的数据都缓存在内存种 ？我曾经做过电信方面的系统，很多表每天入库的数据都是几亿。
4.设计模式，面向对象这些思想也是很好的。但很多方面数据库也有自身的优势。所以取长补短。不能过度设计。
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 23:09
|
|
|
90年代，一个DBA年薪20万，而如今一个JavaEE架构师年薪几十万，说明，如今IT热门已经发生转移，使用OO新技术架构起来的系统，将更加依赖架构师，而不是DBA，DBA只能维护那些老的DB系统，Oracle DB老大已经重点转移JavaEE，是第一个推出EJB3服务器的厂商，老大都闪了，何必那么死心眼揪住数据库呢，那只是10年前的事情了。
现在DBA的待遇不比开发人员低哦，呵呵。当然你不能拿一个普通的DBA跟一个顶级的JAVV架构师比了。
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月12日 23:18
|
|
|
美国的信息产业是世界领先的，那数据库在美国的企业级开发也不是运用很广么，我也曾经跟一个美国软件公司的BOSS交流过，他们就认为数据库是软件系统的地基，所以很强调数据库的优化。
何谈数据库时代过去呢。
[该贴被coder于2008-08-12 23:21修改过]
|
|
|
|
|
|
re:跟BANG老师探讨下
|
2008年08月13日 00:42
|
|
|
都集中在一台db主机上了也就说不上缓存到哪了，数据是可以不在一台主机上的，尽管业务联系很紧密的数据也是可以分散在各个主机上的，它们间的联系是用服务处理的，像用户数据和账目数据虽然是两个联系比较紧密的东西，但是持久的时候不是一定要持久到同一个db主机上的，应用服务器保证了客户看上去这是一个单主机的系统。
有的人说1M内存可缓存4500对象，我不知道这东西准不准，如果准的话1亿对象需要22个1G内存，分散到单独的主机上大约是3台。单机数据库查询出1亿对象要多少时间我就不清楚了，大概不会比缓存效率高。
|
|
|
|
|
这个主题有 44 回复 ／ 3 页
Go
1 2 3
►
|
|
|
注册
登陆
返回本主题
返回页首
.text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://my.poco.cn/fav/storeIt.php?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t)+'&img=http://www.h-strong.com/blog/logo.gif','keyit','scrollbars=no,width=475,height=575,status=no,resizable=yes'));keyit.focus();){kind=logo}
