一次小项目的思考

对banq<<数据库已死>>的反对意见：

1>随着用户的爆发量增长，在某个凌晨醒来时，你发现：数据库已死。
评价：和数据库没什么关系吧，大的网站不做分布式，自动数据分布和失败转移？系统设计的问题，和数据库有毛关系啊。这样说的话，一觉醒来，你发现硬盘坏了，那什么介质都不用用了。

2>著名的社区网站MySpace就是因为一个好的idea，用户疯狂增长，但是系统却不能平滑承受增长的用户访问，这些用户访问网站缓慢、无法访问甚至丢失数据，他们经过几次伤筋动骨的架构升级，在微软SQLServer直接技术支持下， 好容易才勉强应付过去。看看他们痛苦经历，你是否也愿意再来一次呢？详细情况： http://www.jdon.com/jivejdon/thread/34601.html
评价：你经历过？MySpace的人都是傻子？

3>其实2003年国外TSS就有一篇“给数据库休息吧”（休息不代表退休，而是退居幕后，就象操作系统作用一样）
评价：人家是说休息，没有说死亡，这样推的话，操作系统早死亡了

4>所谓伸缩性，就是弹性，整个软件架构既支持小负载运行，也支持大负载支持，只要增加服务器即可；由于软件系统负载已经从SQL转移到内存中的对象上，那么我们就可以通过增加这些应用服务器数量，通过分布式计算甚至云计算，达到业务对象在多台应用服务器之间传递共享，而不必通过数据库这个环节，既减轻数据库负载，又能轻松扩充性能，不必走集中试大型主机之路，只要添置低廉PC服务器即可。经过权威测试：websphere/weblogic的20台PC服务器集群性能不亚于一台SUN/IBM的中型机，性价比已经一目了然了。

　　JavaEE的服务器的集群相对于Linux等操作系统集群的好处在于：JavaEE集群能够针对某个繁忙负载大的具体业务功能进行集群，换句话说： 就是做到精确制导，精确解决问题，而显然，Linux操作系统的集群则无法直至业务核心的。

评价：用c++/c/汇编都可以实现，系统设计的问题等同于使用java就可以解决系统设计的问题，可笑。错误的把集群当成分布式了，集群只是其中一小部分技术

问：
   banq是否做过大的网站，是基于什么样的论调做的数据库已经死亡的结论？感觉他直接命题人工智能可以代替人，远着呢。java使用自己的语言设计操作系统，存储引擎(可以不叫数据库，叫个其他的名字，呵呵)，编译器，分布式模型。如果能做了这些的话，你可以说现在的数据库已经死亡了。

对中国危害最大的是：
a) 数据造假
b)没有数据支撑的乱说比造假更可恶

造假是最可恶的。明明没有做出来，就编造，后边的人没法做出来，还破坏了别人的创新性，成为学术发展的绊脚石。抄袭无所谓，至少不会引导别人偏离正确的研究方向


btw:刚好一个项目结束，有空上来关注。

其实发布这个帖子的目的，其主要关注点还是数据建模与对象建模。可以见无明：[urlhttp://www.iteye.com/topic/1464]数据建模 vs 对象建模 (从Ofbiz帖子切分出来的)[/url]
另外，再次说明，并非指出，不使用数据库。
另外，针对上面的几个问题：
1. 这个是粒度问题，对粒度的把握不准。而数据建模，同样也存在这个问题。[另外，拆分多个细小对象，也并不一定导致表众多]
2. 常量数据无法对应数据库表中，这个无从谈起，请具体说明。
3. 大数据量分页，这个确实依赖于数据库的特定实现。对相当于采用orm如hibernate，其分页函数，则提供了更小的数据库移植成本等(这里只提出这样一个场景，请就要就一般不会进行数据库移植等问题进行回复)。
4. 职责关系不清，这个，应该说相当部分的程序员，对数据库，SQL等掌控不是太好。但相当的数据库管理员，对程序掌握也不是太好。那么，数据库建模，确实也会造成在程序实现上的影响。
5. 采用orm如hibernate，并非就一定不能浪费了数据库能力，上面已经回答过。相反的，在某些场景下，却可以采用对象手段与数据库手段来更好地解决某些问题。
------------------------------------------------------------------------------------------------------------
另外，买Tuxedo的，不一定就是傻子。但，也并非是傻或聪明才能说明的。
比如说需要一些老系统，或是某项目功能必须依赖于Tuxedo。因为曾经有这样个项目，必须使用Tuxedo，而后来又不得不又背一个weblogic。

严重同意，他是站在oracle这个角度说的，实际上，对于整个系统来说，我目前的做法都是能在应用里做的都在应用里做，因为从系统结构上来看，数据库的扩展性远没有应用这头的扩展性好

就这个问题回答给你第5点。

无论对象建模还是数据库建模，都避免不了数据库被污染的问题。出于对数据稳定性的考虑，有了新业务也很难修改原来的表结构，通常是加表了事，结果无论是面向对象还是面向数据库，通通变成四不象。

对于业务逻辑来说，通过SP暴露业务接口和通过Service暴露业务接口是一样的。

确实，将业务逻辑封入SP是一样，而且，确实也有应用采用这种方式。但却问题也非常多：
1. 移植问题[仅提出这样的场景]
2. 业务逻辑更改等问题
3. 事务
4. 。。。。。
另外，见http://www.iteye.com/topic/7266

这差的远了，有一天，你在处理订单的业务的时候，想加上打折的功能，买10000，打个8折，整了半天，发现这个总金额是在存储过程里写的，还得去找DBA来修改，过了两天，老板说，我们要搞个金秋大推广....DBA大哥还维护数据库干吗呢，直接去写业务规则得了

说到底，还是要把事情放在最合适的地方去做，同样DBA也不应该去关心具体的业务逻辑

不好意思 我是半路出家

1>瓶颈的问题，单点永远有问题，系统设计的问题。不是java的问题，不是数据库的问题，是脑子聪明和进水多少的问题。数据库和java也只是讨论工具使用的问题，更具体的java中使用数据库的问题，如果你认为面向对象是最好的，那么：那个牛人设计出了一个面向对象的牛的存储引擎？要不的话，只有你知道这个真理，难道是新时代的爱因斯坦，如果是我的话，我宁愿相信自己不是。当然也有人相信自己是，等待别人做实验证明给看。你看人家goole，一下子就做出一个分布式的BigTable，他也不敢吹自己是分布式面向对象的BigTable，可见不是那么容易的。

2>我们是做应用开发的，还是少炒作概念，务实一点好

个人的理解吧，可能一人对世界一个理解方法。