所以，根本不存在“依赖数据库能一味提高性能”，那只是过去“计划时代”局限下的认识。很多人都没有意识到。所以需要培训和引导变革，说句自豪的话：J道总是在起这样引路变革作用。

呵呵，我不知道，你说得这种集群是你自己测试的，还是看官方的宣传的。
如果你是测试的，那么你能否测试一下我上面给你设计的场景

可以说，现在软件面临的一些问题都是　模型出现的问题，或者是根本不建立模型，或者是不合适的模型． 我觉得，项目成败的关键就是领域模型．而会建立领域模型的系统分析员少的可怜．

Evans　那本书，我一年之前就买了，　可是到现在也没有看，
不是不想看，而是看不懂，因为我想很早学会怎么建立领域模型，　可惜太难了，　可能这也是为什么我觉得领域模型太泛泛的原因．所以实施起来困难太大．

现在玩魔兽世界，大家说暴雪他们是用什么样的架构开发的游戏呢？如果谁能知道它背后的运行机制，恐怕什么企业软件看起来都不复杂了。

我想，在业务层他们是把不同地理区域的运算分派到不同的服务器，所以有时后这里很卡，到另外一个地方就不卡了。持久层他们用了服务器群集，而且在每个点上都大量使用了存储过程，这样才能最大可能的节约成本。这款游戏的升级也很频繁，所以一定也是分好了层次和职责的。

...

坚持存储过程的朋友，可以不必理会包装和层次，待到感觉到将要控制不住的时候再去研究怎么扩展亦可。但一定要有预见性，等性能失控的时候再去改造，恐怕一直以来保持良好增长频率的用户群会变得不忠。

坚持包装和层次的朋友，要强调的不应该是摈弃向数据库要性能，而应该强调在要性能要到极限的时候，应该怎么扩展，怎么从思路上改革，引导更多的人突破极限。

Hibernate等ORM使用方式和误区：
http://www.jdon.com/jivejdon/thread/31684.html

连OLAP和OLTP都不区分，谈什么性能优化？
这两者完全就是两码事。

性能优化是和具体场景密切相关的。没有什么万能的方法。

分布式是为解决什么问题而产生的？

在banq先生看来，这所有的计算都是易并行计算。
通讯开销是0。
同步开销也是0。
加速比是N。

分布式+OO就是解决性能问题的银弹。

越来越发现这句话说的好：同行相轻！

If it is XTP, then that is the first priority.
or else performance should be optimized but not to find the best solution.

to banq,

Definitely you are exaggerating the OO design.
The real IT project is following this methodology:

1. find problems to reach your goal
2. list of your solutions to solve your problems
3. choose the optimized solutions
4. resolve the dependency among these solutions
only in this stage, OO-design comes to play role.
5. implement the solutions
6. debug,test
7 deliver