软件设计经验谈

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

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

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

3，对数据库而言，如何考增加服务器，来提高性能.分区数据库吗?可这个东西，连ibm自已的工程师都说这种方式不能提高性能。

4，不用集群，提高单台服务器的硬件性能，我认为这是最不好的方式，软件太没伸缩性。这种方案会导至用户原来的硬件不在使用，用户会很不满意的。

这叫什么说法，数据库集群如果不能提高性能，那集群跟双机热备有什么区别，那一个集群里有几台几十台机器都是用来干什么的？

不过这里我产生另外两个疑问，我本来相作实验的，但没做，偷一下懒，有人知到的回答一下。
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是多了，数据库要多执行几次，但每次都是单表查询，数据库不会去做表间连接，响应更快，压力会分散在集群中的各个服务器上，减轻数据库服务器压力。不知可行不，有人做过没有，希望高手提提意见。

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

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

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

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

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