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

我不是喷子，这只是真实的感受，其中也包含着很多无奈。。。
JAVA是我第一门掌握的语言，可以说是我在程序设计语言上的母语。也正是如此，我的设计思路从一开始就倾向于OO。已经习惯于把业务场景抽象为object之间的交互，一直以来数据库仅被我作为持久化数据的解决方案之一来看待（其实简单应用的话，格式合理的文件作为持久化也未尝不可）。换句话讲，总是先有应用程序对象模型，再有配套的持久化方案。
然而上班以后才发现，现实完全不需要这样。业务被化解为神圣的表，实体表，引用表，链接表。整个系统非常灵活，所有的程序配置也全部在表里，还有专门的表来记录表和表之间的join关系和一些预先写好的sql子句。真是表中有程序，程序在表中。
JAVA需要做什么呢？对，拼接SQL。代码再恶心也没关系，而且只要面向过程，完全不必担心有性能问题，要知道应用程序的响应时间是纳秒级的，而数据库的相应时间是毫秒级的。万一很慢，那肯定只是你SQL没写好。什么灵活性更是没意义，客户都是外行。只要找个留学归来，擅长沟通，像模像样的客服，耐心给他讲道理：“看似简单的修改，其实我们要增加表，增加字段。。。”，首付都给了，为那么个小修改的成本可能另起炉灶吗？反过来讲，就算你OO厉害，别人程序一改一周，你的程序半天搞定，也只是给项目经理认为是你的改动本身简单，别人的复杂。再退一万步讲，就算客户丢了，那也是客服的事情，销售或者财务出身的老板完全不会把这些怪罪到你头上。
JAVA说完了，回头看看SQL。数据越来越多，系统越来越慢。起初毫秒级响应的操作，慢慢变成秒级，到了分钟级客户就会来抱怨了。这个时候如果你SQL不错就可以自告奋勇去调优，很容易就能发现很多初级错误。简单改改，再优化下索引，效果立竿见影。立刻领导对你赞赏有加，认为这就是技术的力量。。。

我真的很无奈，以上讲的也多少有些极端，其实领导也曾称赞我的OO思想很好，代码简洁、明晰。
只是有时我从一个旁观者的角度来看这个问题。同样能满足一个需求的前提下，两种实现的差距果真有我们设想的这么大吗？
[该贴被scf37于2009-05-29 14:18修改过]

估计楼主所搞的系统，业务逻辑比较简单。只有业务逻辑非常简单的系统，才是主要靠SQL就能解决问题。绝大多数应用不是这样。
我可以举一个例子，Oracle为啥要搞一个PL/SQL？数据库访问问题，不管怎么复杂，用SQL不是都能搞掂吗？
SQL是非过程式语言，或叫面向问题的语言。你只要把问题提出来，它就把结果告诉你，不需要编写过程代码。是比C、C++、Java等过程式语言更高级一代的语言。那为什么Oracle还要补充一个过程式语言PL/SQL给用户呢？因为SQL的高级既带来了方便，势必也带来一些弊病。我以为，至少有两点：
1）系统开销特别大
搞SQL的，都有体会，当系统资源不足时，复杂的SQL语句根本跑不起来。
2）难以实现复杂的业务逻辑
有的DBA能写一些极复杂的SQL语句，很得意，其实，这些语句所对应的业务逻辑仍然是非常简单的。而对与业务数据无关的业务逻辑，SQL一般无法实现，至少是一个很简单的问题被弄得非常复杂。
PL/SQL就能解决这两问题。
但是，PL/SQL的交互能力是非常有限的，绝大多数数据库应用还是离不开常规的高级语言开发工具。

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

呵呵，所以说你得换工作了......
估计你开发的产品应该是很小的应用吧。

我们公司到是大公司，但是开发起来，也都是以sql为主，开发人员主要是编写sql。可见，banq普及OO道的路还有很长啊~

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

我所在的公司做的大型系统业务很复杂，只有以OO思想为指导，开发出来的系统它的可扩展性，可维护性才能体现出来.
[该贴被makeximu于2009-05-30 20:05修改过]
[该贴被makeximu于2009-05-30 20:05修改过]

楼上的意思是unix，linux，windows的可扩展性很差了？？

大多数人都一样，天天淹没在“SQL语句”、“实现功能”、“页面效果”的海洋里,SQL-->功能-->效果一条龙
[该贴被xyh026于2009-05-31 13:13修改过]

我本人所在的单位，做的系统也都是基于数据库的，和java无关，领导喜欢用PB，delph啊，c啊什么的

>>只有以OO思想为指导，开发出来的系统它的可扩展性，可维护性才能体现出来.

太绝对了吧。几年前改签机票，有幸看了航空公司用的系统。纯命令行界面，支撑着全球业务，不知道是那年设计的系统，估计那年代OO还不知道在哪呢。
即使OO确实不错，也别用“只有”这种绝对的词好不好。不能喜欢OO，就否定其他技术吧。

我的经验还有限，接触的系统确实不多，不过应该说并不是很小的应用，我所在的公司是卖CRM服务的，也有很多500强企业的客户。有的大客户的消费者群体也都有上亿（至少对现在的我来说，觉得这个数字挺大了）。可能业务逻辑并不十分复杂，但有些统计需求对SQL的要求的确比应用程序严格很多。
另外我说的SQL就是指PL/SQL或者T-SQL。
还有一点很致命的，不知道其他公司是什么状况，我发现有点岁数的技术方面领导都完全是数据库崇拜者，怎么讲OO啊？我从开始也说了，他们的思路就是先OR映射。。。跟大小应用完全没关系。
还有，其实性能完全不需要担心，性能可以用钱买。如何取得钱只是沟通问题。
想起件好玩的事情，有次我看到一个论坛里程序员们在讨论究竟该用哪一种浏览器有更好的性能，突然有人说，你们这些人吃饱了撑的，正常人碰到网页慢只会说我的CPU太差，要换了，我的内存不够，要添了。。。
[该贴被scf37于2009-06-02 01:17修改过]

>>>我发现有点岁数的技术方面领导都完全是数据库崇拜者
这话说得太绝对，说明你是戴着有色眼镜看世界的。什么有色眼镜？就是“OO万能”。
如果你做的是数据处理应用（你说的，以及当今世界的绝大多数都是），你必须围绕数据做文章。光嘴巴说说，那随便你怎么说都没事。真做起来，必得实事求是。你的应用系统设计的第一步，必须做好数据设计。OO是很后来的东西。把OO想得比数据还伟大，或以为靠OO就能一切搞掂，那是走火入魔。
一个数据处理应用，可以全用DB来做。在某些极端情况，这还是一个不错的选择。
如果全用OO来做，那绝无可能。
数据处理应用，你不围绕数据做文章，围绕OO？为OO而OO？
拿OO来否定DB的人，既不懂DB，也不懂OO。

很谢谢楼上，有一种一语点醒的我的感觉。的确还有太多的路要走。
我决定从头花时间去仔细研究一下数据库建模的方法。
另外我再问个问题，有没有一些规则是可以帮助我在设计时做一些取舍，究竟在遇到具体问题时该为数据考虑更多还是为OO考虑更多。

[该贴被scf37于2009-06-02 14:44修改过]

在设计的最初阶段，重点是数据的规划。在设计业务逻辑层，就得做OOD，然后是OOP。
因此，这是两阶段的活，一般不会有冲突。
我在这里多次说过，拿OO跟DB比，或让一个去否定另一个，那等于让隋唐的秦琼和三国的关羽比试武艺。
[该贴被beepbug于2009-06-02 19:05修改过]

早期的DB，为了便于访问，提高访问效率，只好按访问需求来组织数据。
后来，SQL语句对数据的组织能力越来越强大，设计数据时，就基本抛弃访问需求，而是按数据的内在关系来设计。
数据库技术当然也一直在发展，，或许有一天会按OO来设计DB。但是，至少在现在，还没法这样做。