简单的比较一下 Enterprise, Development 和 Express 等三个版本:以功能言，Enterprise 版和 Development 版的功能一模一样。两者的差别，除了授权不同外，最主要的差别是: 

    Enterprise版的数据库引擎只能安装在Win2003Server(或其他Server)。 

    如果你想安装在WindowsXP Pro系统上，你应该安装SQL2005Development版(开发版)。 

    什么是「数据库引擎」。数据库引擎是SQL2005的核心，是最主要的数据库管理功能模块。没有它，就不是数据库管理系统了。

    因此，如果你是初学者，如果你只是想要在家里学习学习，如果你的环境是 WindowsXP Pro，那么，你应该选择的是 SQL2005Development(开发版)，而不是SQL2005Enterprise(企业版)或SQL2005Express(简易版)。

SQL Server 2005 Enterprise Edition（32 位和 64 位）

Enterprise Edition 达到了支持超大型企业进行联机事务处理 (OLTP)、高度复杂的数据分析、数据仓库系统和网站所需的性能水平。Enterprise Edition 的全面商业智能和分析能力及其高可用性功能（如故障转移群集），使它可以处理大多数关键业务的企业工作负荷。Enterprise Edition 是最全面的 SQL Server 版本，是超大型企业的理想选择，能够满足最复杂的要求。

SQL Server 2005 Evaluation Edition（32 位和 64 位）

SQL Server 2005 还推出了适用于 32 位或 64 位平台的 180 天 Evaluation Edition。SQL Server Evaluation Edition 支持与 SQL Server 2005 Enterprise Edition 相同的功能集。可以根据生产需要升级 SQL Server Evaluation Edition。

SQL Server 2005 Standard Edition（32 位和 64 位）

SQL Server 2005 Standard Edition 是适合中小型企业的数据管理和分析平台。它包括电子商务、数据仓库和业务流解决方案所需的基本功能。Standard Edition 的集成商业智能和高可用性功能可以为企业提供支持其运营所需的基本功能。SQL Server 2005 Standard Edition 是需要全面的数据管理和分析平台的中小型企业的理想选择。

SQL Server 2005 Workgroup Edition（仅适用于 32 位）

对于那些需要在大小和用户数量上没有限制的数据库的小型企业，SQL Server 2005 Workgroup Edition 是理想的数据管理解决方案。SQL Server 2005 Workgroup Edition 可以用作前端 Web 服务器，也可以用于部门或分支机构的运营。它包括 SQL Server 产品系列的核心数据库功能，并且可以轻松地升级至 SQL Server 2005 Standard Edition 或 SQL Server 2005 Enterprise Edition。SQL Server 2005 Workgroup Edition 是理想的入门级数据库，具有可靠、功能强大且易于管理的特点。

SQL Server 2005 Developer Edition（32 位和 64 位）

SQL Server 2005 Developer Edition 允许开发人员在 SQL Server 顶部生成任何类型的应用程序。该应用程序包括 SQL Server 2005 Enterprise Edition 的所有功能，但许可用作开发和测试系统，而不用作生产服务器。SQL Server 2005 Developer Edition 是独立软件供应商 (ISV)、咨询人员、系统集成商、解决方案供应商以及生成和测试应用程序的企业开发人员的理想选择。可以根据生产需要升级 SQL Server 2005 Developer Edition。

SQL Server 2005 Express Edition（仅适用于 32 位）

SQL Server Express 数据库平台基于 Microsoft SQL Server 2005。它也可以替换 Microsoft Desktop Engine (MSDE)。通过与 Microsoft Visual Studio 2005 集成，SQL Server Express 简化了功能丰富、存储安全且部署快速的数据驱动应用程序的开发过程。

SQL Server Express 是免费的，可以再分发（受制于协议），还可以充当客户端数据库以及基本服务器数据库。SQL Server Express 是独立软件供应商 ISV、服务器用户、非专业开发人员、Web 应用程序开发人员、网站主机和创建客户端应用程序的编程爱好者的理想选择。如果需要更多的高级数据库功能，可将 SQL Server Express 无缝升级到更复杂的 SQL Server 版本。

SQL Server Express 还提供了一些附加组件，这些组件都作为具有高级服务的 Microsoft SQL Server 2005 Express Edition (SQL Server Express) 的一部分提供。除了 SQL Server Express 的功能外，具有高级服务的 SQL Server Express 还包括以下功能：

• SQL Server Management Studio Express (SSMSE)，SQL Server Management Studio 的子集。
  
• 支持全文目录。
  
• 支持通过 Reporting Services 查看报表。
  

SQL Server 2005 Mobile Edition（仅 32 位）

SQL Server Mobile 是简版数据库，将企业数据管理功能扩展到小型设备上。SQL Server Mobile 能够复制 Microsoft SQL Server 2005 和 Microsoft SQL Server 2000 的数据，并且允许用户维护与主数据库同步的移动数据存储。SQL Server Mobile 是唯一为智能设备提供关系数据库管理功能的 SQL Server 版本。

SQL Server 2005 Runtime Edition（32 位和 64 位）

SQL Server 2005 Runtime Edition 随 Microsoft ISV Royalty Program 提供。根据 SQL Server 2005 Runtime Edition 的最终用户许可协议，如果用户不使用 SQL Server 代码运行任何其他应用程序或者在任何其他上下文中使用 SQL Server 代码，独立软件供应商 (ISV) 可能将 SQL Server 代码嵌入到他们提供的解决方案中。关于 SQL Server Runtime Edition 的详细信息，请参阅 Microsoft 知识库中的文章如何获取 SQL Server Runtime 许可证 (http://support.microsoft.com/kb/917400)。

注意点：

 在XP上不能安装 Enterprise 版本，

 Express版本只能在本地访问，不能进行远程访问。

 Express版本连接时需要在连接字符串中写 ***\SQLExpress

 Developer版本可以进行远程访问，记住要启用TCP/IP连接，同时要设置好防火墙

数据仓库环境
1.ETL：数据抽取、转化和载入
2.OLAP：OnLine Analytical Processing Engine
3.DSS：决策支持系统
4.客户分析与报表工具
5.其他数据收集和数据输出工具

数据仓库的构架
数据仓库大体可以分为四个层次：
数据源、数据管理与存储层、OLAP服务器和前端工具。
1.数据源：他是数据仓库的基础，位于数据仓库构架的最底层，是数据仓库的数据源泉。包括各个业务处理子系统的信息。
2.数据管理与存储层：是数据仓库的核心。数据仓库如何高效管理数据是区别与面向操作数据库的主要标准。完成按照主题管理数据，聚合数据存放于多维数据库中。
3.OLAP服务器：对数据进行有效集成，按多维模型予以组织。
4.前端工具：主要包括各种报表工具、查询工具、数据挖掘工具等。

有关ETL
数据进入数据仓库的过程一般都要经过抽取（extracted）、转化（transformed）和载入（loaded）三个过程，这个过程被简称为ETL。一般使用现有工具来实现ETL的过程。
1.E:数据抽取。在数据抽取的同时，数据不能被修改。可以抽取的文件格式为：数据库对象，比如表可以整个地从源系统中导出。比如，MS SQL Server 2000的bcp "select * from Northwind..customers" queryout "D:temp.txt"? -c -p -U"sa" -P"sa"。抽取过程为动态抽取，即目标有变化才抽取，不做无谓的工作而影响效率。一种实现的办法就是加时间戳；另一种方法就是分别在不同的表中进行描述。
2.T:数据转化。即将数据从一个系统转移到另外一个系统中。顺序为：源系统 -> staging database -> 数据仓库 -> data mart。有三种方式：a.flat files(无范式) b.区分操作 c.使用交换分区。
3.L:数据输入

其他

数据仓库不一定要用数据库来实现

数据仓库不满足第三范式，并且不满足范式，他只含有“键（key）”。（第一范式：有主键，主观上形象的看，是符合常理的分类或组织；第二范式：满足第一范式，并且所有除主键之外的列都与所有的主键有关系；第三范式：满足第二范式，并且所有除主键之外的列相互之间没有关系）

CREATE TABLE T_CI_YCLLRDZ
(
   FD_YCLLRDZ_ID       CHAR(35)               NOT NULL,
   FD_CIYGBH                 CHARACTER(20),
   FD_CJYGMC               CHARACTER(50),
   FD_WZYGBH             CHARACTER(20),
   FD_WZYGMC            CHARACTER(50),
   CONSTRAINT P_KEY_1 PRIMARY KEY (FD_YCLLRDZ_ID)
);

Declare GLOBAL TEMPORARY TABLE session.temp1 like employee on commit PRESERVE ROWS NOT LOGGED IN mytempspace

这个语句用来声明一个临时表,表明为temp1, 位于现有的表空间mytempspace中(这个表空间必须存在), 和employee表结构一模一样, 每当处理commit语句时,临时表的行就会被保存下来(不会被删除), 最后对临时表的修改不用记入日志. 
     3、ALter语句可以用来改变数据库中的一些特征, 比如[缓冲池(Buffer pool), 模式(Schema), 表(Table), 表空间(Table Space), 触发器(Trigger), 视图(View)], 注意: 不能修改索引, 如果想修改索引, 必须删除该索引后重新添加、例如: alter table t_ci_yclsqjhzb add column fd_sxygbh CHARACTER(20); 为修改表t_ci_yclsqjhzb, 添加一个字段fd_sxygbh。修改字段属性：alter table t_ci_yclsqjhzb alter column fd_sxygbh set datatype CHARACTER(50);

     4、Drop语句用来删除一些数据库特征, 比如包括[缓冲池(Buffer pool), 事件监视器(Event monitor), 函数(Function), 索引(Index), 模式(Schema), 存储过程(Stored procedure), 表(Table), 表空间(Table space), 触发器(Trigger), 视图(View)], 简单的例子 drop table temp, 就是删除表temp.

二、数据库操作语言(DML)

     1、使用Select, 用于检索表或者视图中的数据、例子 select * from temp;
     2、使用Insert, 向表或者视图中添加一条数据, 例子 Insert into temp (字段1, 字段2, 字段3) values (值1, 值2, 值3);
     3、使用update, 修改表数据或者视图中数据、例子1: update temp set 字段1=值1, 字段2=值2 例子2: update temp set(字段1,字段2)=(值1,值2);
     4、使用delete, 删除表数据或者视图中的数据、例子 delete from temp
     5、表中数据非常多的时候，500万条以上，需要使用表分区来提高效率。

三、SQL工具

     1、内连接
     2、外连接(左连接, 右连接, 全连接).内连接时，返回查询结果集合中之仅是符合查询条件( WHERE 搜索条件或 HAVING 条件)和连接条件之行。而采用外连接时，它返回到查询结果集合中之不仅包含符合连接条件之行，而且还包括左表(左外连接时)、右表(右外连接时)或两个边接表(全外连接)中之所有数据行。
     3、就DB2而言, 连接查询的效率要比子查询要高.
     4、Having和where的区别, 只有使用了group by的语句才能使用having.
     5、Case语句在sql 中的应用,例如: select 字段1, 字段2 CASR type when 'T' then 'TABLE' when 'V' then 'VIEW' else 'OTHERS' END from temp,相当于, select 字段1,字段2,table from temp where type = 'T' union all select 字段1,字段2,view from temp where type = 'V';
     6、合并查询Union.

四、SQL函数

1、列函数
  1.1 AVG函数, 平均值的函数.
  1.2 COUNT函数, 计算表中某列的行数.
  1.3 MAX函数, MIN函数,
  1.4 STDDEV函数, 返回一组数的标准方差, stddev函数的参数可以是任何数字型数据类型, 返回结果是双精度浮点型.
  1.5 SUM函数, 求和
  1.6 VARIANCE,返回一组数据的方差, VARIANCE函数的参数可以是任何数字型数据类型, 返回结果是双精度浮点型.
2、标量函数
  2.1 ABS 绝对值, HEX返回值的十六进制表示.
  2.2 LENGTH返回参数中的字节数长度.
  2.3 YEAR抽取参数中的年份.

五、DB2 UDB图形用户界面

1、配置助手, 指令: db2ca, 使用配置助手来配置和维护将要使用的数据库对象, 必须在db2上配置了将要存储的数据库后才能使用这些数据库.
2、控制中心, 指令: db2cc, 用户可以在对象窗格或者内容窗格中选中要操作的对象, 然后右键弹出快捷菜单, 然后通过快捷菜单的命令, 对该对象进行相应的操作.
3、命令编辑器, 指令: db2ce, 用户可以在命令编辑器中输入指令或者调用现成的命令脚本, 然后查看执行后的结果.
4、命令窗口, 指令: db2cmd, 用户可以在窗口中输入命令或调用现成的命令脚本, 然后执行, 并查看结果.
5、信息中心, 指令: db2ic, db2提供了丰富的信息, 几乎所有的信息都可以通过信息中心来获得.
6、开发中心, 指令: db2dc, 开发中心可以完成多种任务, 如创建项目, 添加数据库连接, 创建存储过程, 创建UDF等基本任务, 也可以完成更改环境设置.
7、健康中心, 指令: db2hc.
8、任务中心, 指令: db2tc, 可以创建一些命令脚本.
9、复制中心, 指令: db2rc,

六、DB2安全控制

1、验证，数据库安全性中最基本的概念之一就是验证，这是一个相当简单的过程，系统通过这个过程来证实用户身份。用户可以通过提供身份证明或验证令。来响应验证请求。
2、验证选项，dbm cfg authentication 参数的许多设置在逻辑上可以分组为以下四个不同类别：server（服务器）、client（客户机）、dce、kerberos。
3、server（服务器）缺省安全性机制，指明验证应该使用服务器的操作系统在服务器上发生。如果用户标识和密码是在连接期间指定的，那么 db2 将调用操作系统函数来验证提交的用户标识和密码。（在基于 windows 的环境中，用户标识常被称为用户名。用户名和密码合起来常被称为用户账户。）
4、client（客户机）验证。该组仅有的选项 client 指明验证将在客户机上发生。如果客户机驻留在原本就具有安全特性的操作系统（例如，aix）上，那么它就是可信任客户机。通常，除 microsoft windows 95 和 98 被认为不可信任之外，所有客户机都是可信任的。

七、DB2备份恢复操作

1、整个备份，在控制中心，直接备份，这个备份包括表结构（描述、注释、数据库函数、触发器、存储过程...），恢复的时候也直接在控制中心点恢复库就可以了，这里要注意恢复的路径目录，日期等。
2、db2move方法，一般只用来备份表数据，如果没有表结构也会同时新建表，但是没有其他例如注释、触发器等等的恢复。备份的例子：db2move cjdbgq[tablename] export -u bscj[user] -p baosight[password]，这里也能备份单表。恢复的例子：db2move cjdbgq[tablename] import-u bscj[user] -p baosight[password]；这里需要注意操作的目录，应选择为Dos进入目录。
3、单表数据导出、导入，导出例子：export to c:\test\test.ixf of ixf select * from test；导入数据：import from c:\test\test.ixf of ixf insert into bscj.T_CI_ALERM；这里的import是添加的方式，所以在操作前需要delete from bscj.T_CI_ALERM，把已有数据清除。

hibernate的session提供了一级缓存，每个session，对同一个id进行两次load，不会发送两条sql给数据库，但是session关闭的时候，一级缓存就失效了。

二级缓存是SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置hibernate.cache.provider_class，我们这里用ehcache，在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查询缓存，加上
hibernate.cache.use_query_cache=true

缓存可以简单的看成一个Map，通过key在缓存里面找。

Class的缓存
对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，是POJO。无论list，load还是iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置：

1 < cache  usage ="read-write" />  

如果你使用的二级缓存实现是ehcache的话，需要配置ehcache.xml

1 < cache  name ="com.xxx.pojo.Foo"  maxElementsInMemory ="500"  eternal ="false"  timeToLiveSeconds ="7200"  timeToIdleSeconds ="3600"  overflowToDisk ="true"   />  

其中eternal表示缓存是不是永远不超时，timeToLiveSeconds是缓存中每个元素（这里也就是一个POJO）的超时时间，如果eternal="false"，超过指定的时间，这个元素就被移走了。timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put的元素超过500个时，如果overflowToDisk="true"，就会把缓存中的部分数据保存在硬盘上的临时文件里面。
每个需要缓存的class都要这样配置。如果你没有配置，hibernate会在启动的时候警告你，然后使用defaultCache的配置，这样多个class会共享一个配置。
当某个ID通过hibernate修改时，hibernate会知道，于是移除缓存。
这样大家可能会想，同样的查询条件，第一次先list，第二次再iterate，就可以使用到缓存了。实际上这是很难的，因为你无法判断什么时候是第一次，而且每次查询的条件通常是不一样的，假如数据库里面有100条记录，id从1到100，第一次list的时候出了前50个id，第二次iterate的时候却查询到30至70号id，那么30-50是从缓存里面取的，51到70是从数据库取的，共发送1+20条sql。所以我一直认为iterate没有什么用，总是会有1+N的问题。
（题外话：有说法说大型查询用list会把整个结果集装入内存，很慢，而iterate只select id比较好，但是大型查询总是要分页查的，谁也不会真的把整个结果集装进来，假如一页20条的话，iterate共需要执行21条语句，list虽然选择若干字段，比iterate第一条select id语句慢一些，但只有一条语句，不装入整个结果集hibernate还会根据数据库方言做优化，比如使用mysql的limit，整体看来应该还是list快。）
如果想要对list或者iterate查询的结果缓存，就要用到查询缓存了

查询缓存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache，配置ehcache.xml，注意hibernate3.0以后不是net.sf的包名了

1 < cache  name ="net.sf.hibernate.cache.StandardQueryCache"  
2 maxElementsInMemory ="50"  eternal ="false"  timeToIdleSeconds ="3600"  
3 timeToLiveSeconds ="7200"  overflowToDisk ="true" />  
4 < cache  name ="net.sf.hibernate.cache.UpdateTimestampsCache"  
5 maxElementsInMemory ="5000"  eternal ="true"  overflowToDisk ="true" />  

然后
query.setCacheable(true);//激活查询缓存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可选
第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它：

1 < cache  name ="myCacheRegion"  maxElementsInMemory ="10"  eternal ="false"  timeToIdleSeconds ="3600"  timeToLiveSeconds ="7200"  overflowToDisk ="true"   />  

如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是net.sf.hibernate.cache.StandardQueryCache

对于查询缓存来说，缓存的key是根据hql生成的sql，再加上参数，分页等信息（可以通过日志输出看到，不过它的输出不是很可读，最好改一下它的代码）。
比如hql：
from Cat c where c.name like ?
生成大致如下的sql：
select * from cat c where c.name like ?
参数是"tiger%"，那么查询缓存的key*大约*是这样的字符串（我是凭记忆写的，并不精确，不过看了也该明白了）：
select * from cat c where c.name like ? , parameter:tiger%
这样，保证了同样的查询、同样的参数等条件下具有一样的key。
现在说说缓存的，如果是list方式的话，在这里并不是整个结果集，而是查询出来的这一串ID。也就是说，不管是list方法还是iterate方法，第一次查询的时候，它们的查询方式很它们平时的方式是一样的，list执行一条sql，iterate执行1+N条，多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候，就都和iterate的行为一样了，根据缓存的key去缓存里面查到了，是一串id，然后在到class的缓存里面去一个一个的load出来。这样做是为了节约内存。
可以看出来，查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候，都是既填充查询缓存又填充class缓存的。
这里还有一个很容易被忽视的重要问题，即打开查询缓存以后，即使是list方法也可能遇到1+N的问题！相同条件第一次list的时候，因为查询缓存中找不到，不管class缓存是否存在数据，总是发送一条sql语句到数据库获取全部数据，然后填充查询缓存和class缓存。但是第二次执行的时候，问题就来了，如果你的class缓存的超时时间比较短，现在class缓存都超时了，但是查询缓存还在，那么list方法在获取id串以后，将会一个一个去数据库load！因此，class缓存的超时时间一定不能短于查询缓存设置的超时时间！如果还设置了发呆时间的话，保证class缓存的发呆时间也大于查询的缓存的生存时间。这里还有其他情况，比如class缓存被程序强制evict了，这种情况就请自己注意了。

另外，如果hql查询包含select字句，那么查询缓存里面的就是整个结果集了。

当hibernate更新数据库的时候，它怎么知道更新哪些查询缓存呢？
hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。
当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。
可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。

Collection缓存
需要在hbm的collection里面设置

1 < cache  usage ="read-write" />  

假如class是Cat，collection叫children，那么ehcache里面配置

1 < cache  name ="com.xxx.pojo.Cat.children"  
2 maxElementsInMemory ="20"  eternal ="false"  timeToIdleSeconds ="3600"  timeToLiveSeconds ="7200"  
3 overflowToDisk ="true"   />  

Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。
这样有一个问题，如果你的collection是根据某个字段排序的，当其中一个元素更新了该字段时，导致顺序改变时，collection缓存里面的顺序没有做更新。

缓存策略
只读缓存（read-only）：没有什么好说的
读/写缓存（read-write）:程序可能要的更新数据
不严格的读/写缓存（nonstrict-read-write）：需要更新数据，但是两个事务更新同一条记录的可能性很小，性能比读写缓存好
事务缓存（transactional）：缓存支持事务，发生异常的时候，缓存也能够回滚，只支持jta环境，这个我没有怎么研究过

读写缓存和不严格读写缓存在实现上的区别在于，读写缓存更新缓存的时候会把缓存里面的数据换成一个锁，其他事务如果去取相应的缓存数据，发现被锁住了，然后就直接取数据库查询。
在hibernate2.1的ehcache实现中，如果锁住部分缓存的事务发生了异常，那么缓存会一直被锁住，直到60秒后超时。
不严格读写缓存不锁定缓存中的数据。

使用二级缓存的前置条件
你的hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，hibernate是不可能知道的。你操作数据库必需直接通过hibernate，如果你调用存储过程，或者自己使用jdbc更新数据库，hibernate也是不知道的。hibernate3.0的大批量更新和删除是不更新二级缓存的，但是据说3.1已经解决了这个问题。
这个限制相当的棘手，有时候hibernate做批量更新、删除很慢，但是你却不能自己写jdbc来优化，很郁闷吧。
SessionFactory也提供了移除缓存的方法，你一定要自己写一些JDBC的话，可以调用这些方法移除缓存，这些方法是：

 1 void  evict(Class persistentClass) 
 2 Evict all entries from the second - level cache. 
 3 void  evict(Class persistentClass, Serializable id) 
 4 Evict an entry from the second - level cache. 
 5 void  evictCollection(String roleName) 
 6 Evict all entries from the second - level cache. 
 7 void  evictCollection(String roleName, Serializable id) 
 8 Evict an entry from the second - level cache. 
 9 void  evictQueries() 
10 Evict any query result sets cached in the  default  query cache region. 
11 void  evictQueries(String cacheRegion) 
12 Evict any query result sets cached in the named query cache region. 

不过我不建议这样做，因为这样很难维护。比如你现在用JDBC批量更新了某个表，有3个查询缓存会用到这个表，用evictQueries(String cacheRegion)移除了3个查询缓存，然后用evict(Class persistentClass)移除了class缓存，看上去好像完整了。不过哪天你添加了一个相关查询缓存，可能会忘记更新这里的移除代码。如果你的jdbc代码到处都是，在你添加一个查询缓存的时候，还知道其他什么地方也要做相应的改动吗？

----------------------------------------------------

总结：
不要想当然的以为缓存一定能提高性能，仅仅在你能够驾驭它并且条件合适的情况下才是这样的。hibernate的二级缓存限制还是比较多的，不方便用jdbc可能会大大的降低更新性能。在不了解原理的情况下乱用，可能会有1+N的问题。不当的使用还可能导致读出脏数据。
如果受不了hibernate的诸多限制，那么还是自己在应用程序的层面上做缓存吧。
在越高的层面上做缓存，效果就会越好。就好像尽管磁盘有缓存，数据库还是要实现自己的缓存，尽管数据库有缓存，咱们的应用程序还是要做缓存。因为底层的缓存它并不知道高层要用这些数据干什么，只能做的比较通用，而高层可以有针对性的实现缓存，所以在更高的级别上做缓存，效果也要好些吧。