越来越多人开始使用Java，但是他们大多数人没有做好足够的思想准备（也没有接受Jdon架构培训），以致不能很好驾驭Java项目，甚至 导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。
现在Evans DDD概念很火，因为它将著名的PoEAA进行了具化，实现了PoEAA可操作性，这也是MF大力推崇的原因。
http://www.jdon.com/mda/nlayes.html
[该贴被admin于2008-09-20 18:57修改过]
BANQ的帖子也许质量很高，但是他适合的人群是JAVA水平比较高的那一群吧。什么“ddd”，领域建模，驱动设计，这些东西，对一个JAVA初学者来说根本不知道是什么。就算看了，也不知道它到底是用来做什么的。楼主提出的都是一些新的技术名词。
个人感觉JDON的访问量比不上CSDN的社区，原因是什么呢？BANQ发的帖子的质量应该来说是很好的，也许重要的是初学者那部分人群的丢失。在CSDN社区里，有很多白痴的问题有人回答，这儿的人回答问题的积极性好象不比那高。每天的新帖子都很少。
我欣赏BANQ的精神，但是这个论坛不能只靠BANQ一个人，即使知道的很肤浅，也应该勇敢的表达出来？
当然，还有一个知名度的问题，我是先知道CSDN，才知道JDON的。
祝愿这个社区越来越红火
>banq:
>存储过程和复杂SQL语句的陷阱
> 首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决>性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一>个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗>方案就全部失效，请问你会使用这种短视方案吗？
哎，往往是不得已啊，大家当然明白把业务逻辑放到SQL来实现是不容易维护，可以在处理一些计算量超大的功能中特别是涉及一些大数据分析的功能，使用业务层的服务来实现功能和直接使用复杂SQL实现，性能就是差了级数倍。
要么经常当机，要么选择使用复杂SQL，怎么抉择？就算如BANQ大哥所说在特殊情况把复杂SQL封装成规则的概念，可是在这种规则的实现中，业务逻辑一样是靠SQL实现的，和一般的存储过程有什么不同吗？
总觉得性能和结构设计之间有时是矛盾的，有时不但需要使用复杂的SQL，可能还需要利用很多数据库提供的优化手段来实现，就目前来说，感觉单靠系统的设计还不能很好的解决性能问题，只能在有冲突时，在设计和依赖数据库的性能解决方案之间取得一个平衡点，当然这并容易，不知BANQ大哥有什么高见？
>楼主提出的都是一些新的技术名词。个人感觉JDON的访问量比不上CSDN的社区，原因是什么呢
多谢关心，其实Jdon和CSDN定位不一样，Jdon定位领先启蒙的新技术讨论，从Jdon开站以来，哪样技术不是首先从Jdon首先讨论开始？
GoF 23种设计模式：当时google中文媒体没有完整的GoF 23模式，只有阎宏在天极网上一篇 工厂模式。
Hibernate：最早一批研究Hibernate基本首先在Jdon发帖，后各自发展了，最早之一的Hibernate帖子：http://www.jdon.com/jive/article.jsp?forum=16&thread=9441
Struts: 我2003年10月已经完成《Java实用系统开发指南》，其中已经使用Struts做系统，虽然书籍在2004年1月才印发，而当时都没有一本Struts象样的中文书籍，后来才有各种Struts Hibernate书籍。
最早之一的struts帖子：
http://www.jdon.com/jive/article.jsp?forum=62&thread=91
Spring: 最早之一Spring讨论，探讨Spring真相:
http://www.jdon.com/AOPdesign/spring2.htm
EJB: EJB就不要说了，创站开始就一直谈EJB。
Ioc/AOP： Ioc最早普及研究帖子之一：
http://www.jdon.com/jive/thread.jsp?forum=91&thread=11673
当初提出数据库时代终结，招来一批反对，见这个帖子：
http://www.jdon.com/jive/thread.jsp?forum=91&thread=20162
现在DDD，不知谈论，在一年前已经讨论，并且作出JdonFramework 1.3这样DDD框架。
总之，J道网站定位在创新开拓、启蒙引导，在众多新技术中凭独到眼光挑选中未来会成为主流的技术进行讨论和研究，都是重要的技术。
这些是其他网站都不能比拟的，正因为J道定位在高端、新，所以，访问量知名度不可能大众化，但是专业领域到高端都应该知道的。
>总觉得性能和结构设计之间有时是矛盾的，有时不但需要使用复杂的>SQL，可能还需要利用很多数据库提供的优化手段来实现，就目前来说，感觉单靠系统的设计还不能很好的解决性能问题
我文中的意思你可能还不明白，或我没有表达清楚：就算你使用复杂SQL优化了性能，但是这个优化之路有一个天花板，只能是一两台数据库服务器，它们能顶多少互联网访问量？
再者，目前显示证明，使用内存缓存来优化，性能更好，道理很简单，将应用服务器和数据库服务器运行原理稍微对比就可以知道：
数据库服务器依靠大内存和磁盘I/O，后者往往是瓶颈；
再看看内存运行效率比较：由于采取DDD，我们的对象模型都是和具体业务相关的提炼，是我们程序员根据具体系统定做的，因此内存重用效率很高；但是业务模型不是和数据表一对一对应，而且数据库考虑到其他通用算法问题，数据库的内存缓存重用效率就没有应用服务器高。
换句话说：J2EE应用服务器缓存可能是我们为这个业务系统定做的；而数据库服务器我们无法做到这点，很显然定做的效率和性能要更高。
而且应用服务器可以靠分布式缓存或集群增加N台服务器，目前webpshere20台服务器集群性能是惊人的。
所以，根本不存在“依赖数据库能一味提高性能”，那只是过去“计划时代”局限下的认识。很多人都没有意识到。所以需要培训和引导变革，说句自豪的话：J道总是在起这样引路变革作用。
其实一直很佩服Banq.
>其实一直很佩服Banq.
我这是抛砖引玉，虽然有时会引来一些玉砖，被狂拍，这也是好的啊。软件就讲究新，希望新的高端的定位吸引一直能够保持refresh的各位道友。共勉。
对于banq的这篇文章，我是比较赞同的。但有一点，老大并没讲到。什么分层也好，框架也好，最适合客户需求的才是最好的。
所以，对于文章中提到的存储过程。本人认为它并不是那么讨厌。在某些情况下它还是能带来好处的。
>GoF 23种设计模式：当时google中文媒体没有完整的GoF 23模式，只有阎宏在天极网上一篇 工厂模式。
>Hibernate：最早一批研究Hibernate基本首先在Jdon发帖，后各自发展了，最早之一的Hibernate帖子：http://www.jdon.com/jive/article.jsp?forum=16&thread=9441
>Spring: 最早之一Spring讨论，探讨Spring真相:
http://www.jdon.com/AOPdesign/spring2.htm
>Ioc/AOP： Ioc最早普及研究帖子之一：
http://www.jdon.com/jive/thread.jsp?forum=91&thread=11673
恩恩，举出这么几个例子……
我只有一句话：人不能不要脸。
要不要我把这几个帖子背后的故事再讲一遍？
>我只有一句话：人不能不要脸。
你可能将我和J道混为一谈了，这些最早之一的帖子并不都是我发表的，而是由象您这样的高手首先发表，有时我也从中学习，只不过，我将各家之长吸纳消化，通过J道再反馈给其他初学者，和大家一起进步学习，我相信这种人机混合的智能学习型网站模式是未来专业网站必由之路。
banq，高尚的高手，，佩服！！！
感觉有一些偏颇吧
从我的经历说一说
1、表设计的问题，有很多项目是在别的项目上进行扩展。当然你可以在重新生成一套符合你设计的表，不过一般来说不会使用这种方式，特别是大数据量的冗余成本太高。
2、是否采用存储过程。我的一般经验是能用还是尽量使用，存储过程也是一个对于业务的封装，比如sp_ModifyPersionInfo，我想你看了你就明白这个东西干吗的，你用DAO层调用会损失什么那？？当然你会说这样损失了系统的可移植性。不过如果一个系统有上百个存储过程的系统你觉得它具备让你移植的必要么？？
3、java的局限性：至今我没有看到java实现的关于数据分析及数据钻取方面的应用，一般来说数据分析，数据仓库仍然采用传统的方式，j2ee尚不能脱离数据仓库独立的完成该功能。
4、Hibernate的问题。我没有怎么学习Hibernate，在我的印象中它是一个or映射的工具。or映射这个问题讨论了很多年，但是我个人觉得尚没有一种完全的解决方案来实现复杂对象的持久化问题（xml可以，但是对于大数据量应用太慢，而且由于自描述的特性，冗余必然过大）。Hibernate我觉得应用在一些简单的应用上尚可，应用于复杂应用就算了。
看了第一句就有点FT，这么明显的带有宣传意图。即使你说的再好，给我的感觉还是一个商人，而优秀的商人比比皆是，不欠你一家，寓意中感觉不用你的东西就不是好东西似的
顶，我觉得bang说的很对，jdom也许访问量不是最大的，但是其质量确实很高的。关键还是定位的不同
楼主应该属于理论型的专家，如果你亲自去实施一个大访问量的项目，你就不会这么说了。
对于你的观点，我觉得你只说对了一半，因为你并没有为你的观点提出一个适用的场景，那么下面我给你描述一个场景，你看看，如果你不使用存储过程的话，效率会不会更高：
假定有一次操作，这次操作涉及到了10个业务对象，这些业务对象会频繁更新，也就是说，如果你要在内存中缓存的话，你必须要保证你的集群中的每个应用服务器中，缓存的这些数据是同步的，而且是最新，而且每次更新必须要保证持久化到db。
这样一来，可能你所说的缓存意义不会很大，因为就算你使用了ejb，在这样的要求了，如果你使用缓存，那么同样会影响你在集群中节点的数量（节点越多，同步数据的负载越大）。所以可能你会考虑不缓存这些数据，这些数据直接从db中读取，那么问题就来了，这10个对象在数据库中，我想你不仅仅使用一个表存储，你至少会存储在多个表中，那么在这种情况下，如果你不是用复杂的sql,或者 存储过程，那么你的这次操作必然会对应对此的数据库操作，相比较而言，这多次的Sql对于db来说，它加重了db的负载，而且耗费了连接数，耗费sql编译的时间。在这种情况下，如果按照你的说法，不使用复杂sql，不使用存储过程，我不知道在性能上你怎么能够达到要求。