两年程序员的感悟,SQL才是重点,JAVA无所谓。

09-05-29 scf37
我不是喷子,这只是真实的感受,其中也包含着很多无奈。。。

JAVA是我第一门掌握的语言,可以说是我在程序设计语言上的母语。也正是如此,我的设计思路从一开始就倾向于OO。已经习惯于把业务场景抽象为object之间的交互,一直以来数据库仅被我作为持久化数据的解决方案之一来看待(其实简单应用的话,格式合理的文件作为持久化也未尝不可)。换句话讲,总是先有应用程序对象模型,再有配套的持久化方案。

然而上班以后才发现,现实完全不需要这样。业务被化解为神圣的表,实体表,引用表,链接表。整个系统非常灵活,所有的程序配置也全部在表里,还有专门的表来记录表和表之间的join关系和一些预先写好的sql子句。真是表中有程序,程序在表中。

JAVA需要做什么呢?对,拼接SQL。代码再恶心也没关系,而且只要面向过程,完全不必担心有性能问题,要知道应用程序的响应时间是纳秒级的,而数据库的相应时间是毫秒级的。万一很慢,那肯定只是你SQL没写好。什么灵活性更是没意义,客户都是外行。只要找个留学归来,擅长沟通,像模像样的客服,耐心给他讲道理:“看似简单的修改,其实我们要增加表,增加字段。。。”,首付都给了,为那么个小修改的成本可能另起炉灶吗?反过来讲,就算你OO厉害,别人程序一改一周,你的程序半天搞定,也只是给项目经理认为是你的改动本身简单,别人的复杂。再退一万步讲,就算客户丢了,那也是客服的事情,销售或者财务出身的老板完全不会把这些怪罪到你头上。

JAVA说完了,回头看看SQL。数据越来越多,系统越来越慢。起初毫秒级响应的操作,慢慢变成秒级,到了分钟级客户就会来抱怨了。这个时候如果你SQL不错就可以自告奋勇去调优,很容易就能发现很多初级错误。简单改改,再优化下索引,效果立竿见影。立刻领导对你赞赏有加,认为这就是技术的力量。。。

我真的很无奈,以上讲的也多少有些极端,其实领导也曾称赞我的OO思想很好,代码简洁、明晰。

只是有时我从一个旁观者的角度来看这个问题。同样能满足一个需求的前提下,两种实现的差距果真有我们设想的这么大吗?

[该贴被scf37于2009-05-29 14:18修改过]

    

4
beepbug
2009-05-30 06:32
估计楼主所搞的系统,业务逻辑比较简单。只有业务逻辑非常简单的系统,才是主要靠SQL就能解决问题。绝大多数应用不是这样。

我可以举一个例子,Oracle为啥要搞一个PL/SQL?数据库访问问题,不管怎么复杂,用SQL不是都能搞掂吗?

SQL是非过程式语言,或叫面向问题的语言。你只要把问题提出来,它就把结果告诉你,不需要编写过程代码。是比C、C++、Java等过程式语言更高级一代的语言。那为什么Oracle还要补充一个过程式语言PL/SQL给用户呢?因为SQL的高级既带来了方便,势必也带来一些弊病。我以为,至少有两点:

1)系统开销特别大

搞SQL的,都有体会,当系统资源不足时,复杂的SQL语句根本跑不起来。

2)难以实现复杂的业务逻辑

有的DBA能写一些极复杂的SQL语句,很得意,其实,这些语句所对应的业务逻辑仍然是非常简单的。而对与业务数据无关的业务逻辑,SQL一般无法实现,至少是一个很简单的问题被弄得非常复杂。

PL/SQL就能解决这两问题。

但是,PL/SQL的交互能力是非常有限的,绝大多数数据库应用还是离不开常规的高级语言开发工具。

xmuzyu
2009-05-30 13:16
现实就是存在很多无奈。公司里面不能完全OO是有原因的,原因有很多。我觉得还是看个人兴趣吧。比如公司的项目,那么就采用大家都熟悉的,无论是SQL和OO都可以,只要采用大家都比较接受的一种即可。但是我在自己的项目(自己和朋友接的单)中,我就采用OO。因为我对OO有兴趣,我学习OO是兴趣导向的。

DLUTkaka
2009-05-30 14:25
呵呵,所以说你得换工作了......

估计你开发的产品应该是很小的应用吧。

forest3000
2009-05-30 18:56
我们公司到是大公司,但是开发起来,也都是以sql为主,开发人员主要是编写sql。可见,banq普及OO道的路还有很长啊~

至于系统的性能,只要服务器性能好,在加上sql写的好,也还是不错的,不过,维护起来简直就是噩梦!

猜你喜欢
10Go 1 2 3 4 ... 10 下一页