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

yinyousong 08-10-29
                   

前几天学校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修改过]

                   

banq
2008-10-29 17:40

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

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

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

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

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


banq
2008-10-29 18:15

相关帖子:

MVC怎么区分?
http://www.jdon.com/jivejdon/thread/34785.html

关于JAVA EE状态管理
http://www.jdon.com/jivejdon/thread/34825.html

谈谈java的类与对象
http://www.jdon.com/jivejdon/thread/34820.html

freeren
2008-10-29 23:31

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

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

usherlight
2008-10-30 09:58

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

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

13Go 1 2 3 4 ... 13 下一页