软件设计经验谈

在高性能环境下，H反而成本更高！

复杂查询建视图，这样结构很清晰

可做个物化视图，数据库端做个缓存

还可以做个应用级别的缓存，对关键数据进行缓存

页面级别的缓存也可以用

不过应用级的缓存是最有效的

分区，索引可以适当食用

有时候也要考虑一些变通的办法，比如楼主提出的第一个学生选课的问题。

学校一般没什么钱来给你配置好的服务器（而且经常是一个服务器上跑着很多个应用，光是应用服务器和CMS通常都有运行着好几个不同的），数据库也基本用的是MySQL这样在他们看来“免费的软件”……

那么就可以尽量争取让服务器的内存容量大一些，MySQL允许的并发连接稍微多几条（同时一定要仔细谨慎地配置一个数据源/JDBC连接池来维护这些连接），MySQL可以获取使用的内存也适当加大一点……

如果使用了Hibernate的话，良好的持久化关联关系配置、合理的缓存规划、逻辑清醒的业务代码……这些都可以提升应用程序的可延展性。

最后，也是最现实的一点（也许可以说是最管用的一条）——和学校这方面的负责人协商一下，改善一下学生选课的流程，适当延长选课的时间段，不要让所有学生都同时在使用你们的选课系统。（一个普通的大学一般都有数以万计的学生，如果很短的时间段里他们同时在你们的系统上进行操作，那么很难相信学校这种近乎业余级别的服务器可以承受得住。）

关注！了解性能不多，但碰到类似的问题，解决方法正在寻找

也在学习Hibernate,看上面的发言都有点怕了 

Allen 说得对！学校一般不大可能配置多台服务器。如果数据库和WEB服务器都装在同一台服务器中。要想性能方面由提升，就要考虑增加内存。当然还有CPU。现在服务器一般都支持多CPU。

这和用什么开发工具没关系，如果你将数据存取和数据计算分离，那么就可以做到分布式运算，可以用多个普通PC机，一起计算(数据分类)后将结果存入数据库！

谢谢楼上的各位，看了后有所收获。疑问如下：
1.关于hibernate 的集群问题，我已搜过相关在贴子，没看到实际可行的方法,有人说用支持集群的cache，用这过个东西，我不报太大的希望，至少我没听说过有什么太好的产品。不知到有人用过这种方式没有,如果有，希望分享一下（关建还是cache同步对性能的影响，有几位老兄已经提出这个问题了）。或者有人给过有这种解决方法的联接.
2,查询与计算分开，这在业务复杂时应该是一下好方法，减轻了数据库的负担，但对以下两个例子而言，只存在查询与更新，没有什么复杂的计算。
3.有位老兄提出说学校硬件太差，就实际我遇到的情况而言，硬件环境还是不错的，到少都是4G内存，2cpu/4cpu.不过最后确实如老兄所说，与学校协商，学生选课按学院分了一下，减少并发，看来穷则变，变则通呀。

不过这里我产生另外两个疑问，我本来相作实验的，但没做，偷一下懒，有人知到的回答一下。
1，对一个复杂的sql,我们是分成一个一个的小sql好，还是一个大sql好，我想分成一个一个的小sql可能在大并发时，能提高性能 ，
如
select * from (select teacher.*,student.*,rownumber() over(ORDER BY studnet.id ASC) AS rn  from select * from teacher left join studenton teacher.id =student.teacherId) where rn >=0 and rn <15,
对这样一个查询，我们一次只需取15条记录 ，如果我们改一下，改成如下方式  
select teacher.id from teacher,
select * from (select *,rownumber() over(order by id) from student where teacherid in("t1","t2",,,)) where rn>=0 and rn<15

这样一个（上面sql有优化的地方，只是示例用，就不优化了），sql是多了，数据库要多执行几次，但每次都是单表查询，数据库不会去做表间连接，响应更快，压力会分散在集群中的各个服务器上，减轻数据库服务器压力。不知可行不，有人做过没有，希望高手提提意见。

2,老有人说，创建太多的对象影响性能，这个不否认。但是到底会关生多少性能影响(先否定太多的对象的情况，如很多str相加的情况)，就拿数据库操作而言，你从数据库中得到一个学生的数据 包括(name,sex,age,addree,)  把这些存在一些变量中，与存在一个studnet（如通过hiberante获得） 这样一个对象中，两者之间到底会关生多少性能影响。          

Hibernate的性能关键体现在实体的模式抽象度是否足够!类似ejb的Session facade模式!至于集群的问题!我个人认为以product pre analyse不够充分!集群以硬件环境换软件环境是一种高成本,高维护的措施!

至于楼上列举的一种sql,这种无任何封装的业务模式是非常愚蠢的和不可取的!首先sql的操作是不保持连接的,这首先就是一种性能上的丧失!并且大量的曝露了数据结构,死板的设计模版.

其实业务的性能最多丧失在网络和数据库上!争对网络的优化我认为应该把重点放在锐化网络通行上!一如采用代理(agent)的模式来代替裸露的协议!对一些通信要尽可能的封装(单纯的把identify包装)!而争对数据库的优化要争对数据的sync和连接的保持!数据的sync是实时性要求很高的系统中经常遇到的!如果在sync的时候不保持连接(或者有效的保持连接或者条件性的保持的连接)是优化数据库的有效方法!