数据库岂能不亡?---->??

前几天学校asp.net实验室招人,去问了下:主要考一些存储结构、触发器.本想进去锻炼下的,但内心的真是想法让我连报名都不想去了.

在数据库里写存储结构、触发器.无异于面对sql语句编程,java只是一个小丑,对象是被sql强奸了的DTO.将大量的业务逻辑置于存储结构中,乍一看好像是为了提升系统的处理速度,但随着系统变大、访问量提升,最后数据库自己宣布此系统以死,请换个新的系统吧.学生为什吗这么讲,主要因为以下几点:

1、将业务逻辑置于存储结构,无异于将所以的负载集中到数据库中.首先当客户请求到达时,DAO将客户的参数送于数据库的存储结构里执行,然后返回结果.这样的构架只会让数据库疲于奔命.

2、使用Hibernate缓存数据,这好像是缓存,但实际上这些个缓存被击中的几率有多大呢?客户请求到达时,DAO携带着客户的参数让存储结构去数据库执行计算,然后封装成DTO返回给客户.这样的缓存能被击中吗?因为业务逻辑是要送到数据库去计算的,当新的请求或者客户请求参数变动,那么又得重新跑到数据库去计算;为何?因为你针对的是sql编程,你的对象只是一些所谓的DTO而已.这样一来你会觉得,用什么Hibernate啊,它把系统速度拖慢了,还不如直接使用JDBC来的爽呢?

3、如果你认为数据库的缓存已经很强大了,或者你说数据库群集,那我想只有你老大微软.NET才能帮你.关于数据库的坏味道我就不在阐述了,很多高人都已经将的很清楚了.

我为什么会有上面的思考,主要是基于一下几点:
1、我们将业务逻辑放在java代码中,根据DDD思想进行设计,DB只负责对象的重建.如此一来将负载集中在JBOSS等容器中.

2、我认为DDD最大的好处是能减少和数据库的交互.利用聚合等设计模式对领域对象进行建模.起初好像客户每次请求都会加载很多对象,然而由于我们将业务逻辑置于java代码中,当访问量增大,那些经常被访问的对象即可被容器或Hibernate缓存,随着时间的流逝,这种缓存会越来越精确,从而让容器流更多的汗.!

3、当容器跑不动时,简单的增加硬件配置便能让处理能力成倍提升,让对象在几台服务器上跑来跑去,跑累了就在内存里洗个澡,岂不快哉?!

我现在才觉得EJB的设计理念是那么的超前,然而国内却流行"简单就是美",使用spring对EJB的设计理念避而不谈,只讲:企业很少用到EJB的,spring简单实现的东西在EJB那里很复杂.不知道我们的思想是不是离美国人还有很远?

还好,现在有seam了,可以多一些选择,如果我能做主的话就对spring 说消失吧.以上只是学生的一点小想法,如果有理论性的错误,那就请您先去戴双手套,然后捡起砖头猛拍,这样您即拍的爽,手也不会被刮伤.


[该贴被admin于2008-10-29 17:29修改过]

>使用Spring对EJB的设计理念避而不谈,只讲:企业很少用到EJB的,spring简单实现的东西在EJB那里很复杂.不知道我们的思想是不是离美国人还有很远?

这是很典型的掩耳盗铃做法,现在Spring即将支持EJB,与EJB融合,说明Spring fans们过去鼓吹的without EJB是不可能实现的,从而也说明他们过去的观点是多么井底之蛙,在这样狭隘理念下讨论和学习Java,无疑是自寻死路。

在企业软件架构选择确定之前,我们无疑需要一个鸟瞰高度,而不能以是否复杂回避。

我本人是非常讲究设计之巧妙,讲究大道至简的人,从我喜欢水墨画这个爱好就可以看出,中国水墨用黑白演绎世间一切对象,多么精妙令人回味,我这样一个讲究设计简单的人一直推崇EJB,说明EJB不是为复杂而复杂,其复杂原理包含对象生命周期等动态scope概念,这些对象设计理念才是“复杂”的。

其实对象设计理念本身不复杂,那么自然,符合自然之道,是因为我们的思维曾经被“邪恶”误导了,再看正常的哲学之道以为复杂,根源就在这里,中国软件落后美国的原因也在这里:教育培训的落后。


>>将大量的业务逻辑置于存储结构中,乍一看好像是为了提升系统的处理速度,但随着系统变大、访问量提升,最后数据库自己宣布此系统以死,请换个新的系统吧.

这点是深有体会,现在我们的设计也基本上是由数据库来驱动的。比如我们会把关联以表ID放到主表,但是在页面上我们也需要看到name,ok,再把name也放进来。这时又有个code--手工输入维护的,又放进来,其作用类似ID,是唯一的。到时我们要在页面看一些业务对象比如订单,订单有包括产品、客户。把产品ID、名称、客户ID、code(编号)、名称也放到主表(订单)中来。显示就会显示订单的主要信息还有产品的名称、客户的名称。这时这样的设计MS没什么问题,接下来,需要变了,用户可以会把更多的产品信息显示出来,是不是要到订单表也再多加几个字段,那如果客户呢,又如果订单还有其他信息呢?因此,可见其扩展性。看得出来我们的设计在考虑上的出发点是好的,总能想到怎么去更好的查询到数据,但是扩展性可能考虑得太少了!

将负载转移到应用服务器上也并不是没有问题的。
诸如:session复制,所有应用器之间的数据同步
根据我的理解,集群的性能与集群的服务器数量并不能正比,也就是说并不能通过简单的增加应用器的性能来提高性能(在集群中)
请问,这时候,怎么办?

另外,也请慎用数据库死亡之类的标题。
根据你的描述,你的应用最后还是将数据库持久化到了数据库中。
并不能真正的抛弃数据库。
何来数据库死亡的说法?

呵呵,这只是小弟的一点反思,由于小弟是学生,很多东西都是基于理论的,所以其中肯定有大量的错误,还请各位高人讲解在企业中是如何完美的应用数据库的,学生希望学的更多.!Thanks

实际上把所有的业务逻辑放在储存过程,然后调用存储过程返回的结果,这样的公司在现实中也存在,
存储过程个人感觉到唯一的好处就是所谓的测试方便,exec produre_name parameter.... 就能在数据库图形化界面看到结果,其他的没什么,维护也困难,需要专门的DBA

怎么又是这样的标题党?我爆发了!!!!!!!!!!!!!!!!!!!!!
怎么这里一说到数据库就像遇到鬼似的
别一天到晚就嘴巴说OO,记住OO是设计思想.别搞得OO和数据库水火不容一样.不行就先去看看数据库范式.说数据库死,你有种别用数据库做系统,SQL提供这么强大的查询功能有哪个ORM产品能比
整天拿分布对象缓存说事,做过的又有几个,你做过吗?
再说了,现在类似内存数据库的数据库缓存产品不都有了么
我倒觉得数据库不但不会死 反而会活得更好
我想,数据库以后很可能会发展成:内存缓存数据库产品+离线存储产品
2个东西统一成为一个数据解决方案,产品提供2端的同步算法与策略

[该贴被admin于2008-10-31 19:28修改过]

相信数据库不但活得很好,而且有大发展,就像windows操作系统,windows 7都出了。

可是我们做以及学企业软件,还需要接触和学习windows 7这样的操作系统吗?

数据库和操作系统一样,已经从我们企业软件架构中死去。

数据库软件,数据库思维已经在软件架构中死去
为什么还有这么多的人读不懂?
关系数据库,xml文件,对象数据库,对象缓存,这些都是存放对象地方啊,这些存储介质,存储类型都服务于领域模型,banq强调的是架构思维。

以jivejdon为例子,要做的话,我可以很快实现三个版本,关系数据库版本,xml文件版本,DB4O对象数据库版本。

Sorry, I can not type chinese in shool's lab

Banq, I am quite disagree with your point:

现在Spring即将支持EJB,与EJB融合,说明Spring fans们过去鼓吹的without EJB是不可能实现的,从而也说明他们过去的观点是多么井底之蛙,在这样狭隘理念下讨论和学习Java,无疑是自寻死路。

I think you misunderstand one thing: What Spring against is EJB 2.1 and its perious version. Programming without EJB is also for EJB 2.1. In my opion, the pervious EJB is already dead. Look at the latest version of EJB, it changed so much that I just don't think it is a same product for the old EJB.

Also, look at what kind of techniques used in EJB 3:

Dependency Injection and AOP are similar with Spring

ORM is similar with JPA

I think in some level, it prove that we can really develop a program without using EJB 2.1 and its pervious version.

>>说数据库死,你有种别用数据库做系统,SQL提供这么强大的查询功能有哪个ORM产品能比
那你只用数据库来做个系统看看。banq老师讲的是架构的思想。数据库只是一个存储数据的地方。说数据库死,不是不用数据库,而是数据库和我们的软件业务没什么关系,我们的软件业务要通过对象来实现,数据库只是一个存储的地方,与业务没关系。

为什么hibernate等ORM这么流行,就是因为它屏蔽数据库关系原理,让我们更好用对象来实现业务。再说了通过对象来处理业务是很自然的,更加符合我们的思考方式。为什么是先有面向过程,然后才右面向对象,有点哲学思维的人都知道,事物处于不断地发展,演进中。我们设计也是一样,从面向过程到面向对象,这是一种进步,是一种发展。我想以后就算有一种思想能替代OO思想,那么那个思想也绝对不是面向过程,因为这是倒流,倒退。

纯属个人观点。

>without using EJB 2.1 and its pervious version
楼上狡辩了,那你就写明白一点without ejb2.1啊。话说得那么死,EJB是标准,总会发展,干嘛说死了呢?就象我说你这辈子没治了,你生气吧?盖官定论。

但是我对关系数据库在企业架构位置就可以盖官定论说,无论数据库怎么发展,关系数据库在企业架构早死了,两者不一样啊。

关于是EJB3向Spring学习,还是Spring向EJB学习(比如添加@PostConstruct @PreDestroy等EJB2/EJB1.X早就有的这些定义 ),就说不清楚了,关键是EJB是否学习得丢失了自己的分布式组件架构的灵魂呢?EJB学习了让自己变得更易于使用,这有什么不好;就允许你Spring一个人漂亮,其他人打扮漂亮了就是跟你学习?

什么心理,简直一个小孩心理,不跟你讨论了,你认为别人跟你学习你就美去吧。这世界上就兴你Spring一个人用IOC/AOP了,别人用了就是抄你学习你,那就没有模式和架构发展了。


有没有搞错,EJB3出了之后spring才加入那些标记的,这的确是学习,但是EJB3支持IOC则是从开源框架借鉴的(当然不一定是Spring)。JPA学习Hibernate,EJB3支持IOC,技术之间互相借鉴学习是非常正常的。EJB2.1之前确实没法用,开发效率低的一塌糊涂,EntityBean的性能也令人不敢恭维,我用过2年的EJB2,实在是噩梦。所以才有WithoutEJB,说这话的时候EJB3绝对没有诞生,现在EJB和Spring都升级了。Rod最近又指出了EJB3的一些问题,我觉得这是好事,当然他也有借此推Spring的想法。

PS:类似@PostConstruct @PreDestroy功能Spring早就有,只不过不是以Annotation的形式提供的。

[该贴被admin于2008-11-02 19:21修改过]

>我用过2年的EJB2,实在是噩梦
我用EJB2从来不觉得噩梦,因人而异吧。我们不能再范睡不着觉怪床歪的事情了。

>类似@PostConstruct @PreDestroy功能Spring早就有
什么早就有?至少1.x版本没有,Session状态支持也没有,这些我都在Jdon框架说明中写了。

我知道你是从来不看我的Jdon框架的,所以,你的眼界就很有小,说话就带小人之语,我就利用admin权限修改你的言论,你不服就自己在你博客上反击吧,我已经经历很多次,至今好像一直活得好好的,因为我掌握真理。