【IT专家网独家】用户需求：

　　现在有一个员工绩效考核系统。在这个系统中，员工信息表是其最基本的表格之一。现在假设该表格中有五位员工信息，具体记录内容如下：

　　员工ID　　员工姓名　　入职时间

　　SA001　　王晓　　1999年5月10日

　　SA002　　丁含　　2005年3月12日

　　AD001　　郑洁　　2006年1月15日

　　PD001　　周良　　2008年3月10日

　　PU003　　丁科　　2006年5月9日。

　　现在人事文员发现员工编号为PD001的员工姓名写错了，其不应该为周良，而应该为周梁。正在对这条记录进行修改，在修改的事务还没有提交之前，此时有其他人也在访问这个表格。那么该系统该如何处理呢?

　　具体的处理方式，两个数据库系统各有特点，下面，笔者将对此做具体的介绍。或许从笔者的介绍中，你能够找到一种适合自己的处理方式。

　　SQL Server的处理方式一：Read Repeatable

　　这是SQL Server数据库设计时利用的最多的处理方式。这种事务隔离级别的特点主要有两个：

　　1、其他用户只能够度曲其他事务已经提交的更新结果，否则的话，就会发生等待。如以上这个表中，当人事文员正在修改员工编号为PD001的记录的时候，此时，若恰巧人事经理需要查询员工PD001的入职时间，此时，若采用这个事务隔离级别的话，人事经理是无法查询这条信息的;只有等人事文员把这条信息修改好了，把事务提交了，则人事经理则会查询到这条信息。

　　2、其他用户可以修改这个事务中已经被读取的记录，而不必等其他事务的完成。如当人事文员在修改员工编号为PD001的记录的之前，人事经理已经在查看员工编号为SA002的信息，此时，即使人事文员对记录PD001的修改事务没有提交之前，人事经理仍然可以对SA002的记录进行修改，如可以修改他的入职日期等等。

　　也就是说，这种处理方式是通过对记录进行加锁。若其他员工对某条记录在进行修改操作时，则数据库会给这条记录进行加锁。此时，其他任何人都无法对这条记录进行修改。但是，这只是影响到用户正在修改的记录。对于用户未修改的记录没有任何影响，其他用户仍然可以进行查询与修改。

　　这种方式是比较常见的事务处理方式，在很多系统的数据库设计中，都是采用这种处理方式的。如在ERP系统数据库设计中，不同的采购员就可以同时对各自的采购单进行修改，而不会相互之间产生影响，就是采用了这个事务隔离方式。

　　SQL Server处理方式之二：Read Commited

　　这是SQL Server数据库默认的处理方式，不过，这不是最常用的处理方式。这个处理方式的特点如下：

　　1、这种事务的隔离级别只能读取其他事务已经提交的更新结果。读取数据的时候，若其他人正在修改这条数据，则只好等待。这跟上面处理方式的第一个特点是一样的。

　　2、主要区别在于这一点。若人事经理先查询了PD001这条记录，此时，人事文员发现了这个员工的姓名有错的话，进行修改;在其没有修改完成之前，人事经理也发现了名字有错误，此时，其也可以进行修改。显然，在这种处理模式下，一个修改事务中的两个相同的读取操作，最后的结果可能会有所不同。

　　这个处理方式，跟第一种处理方式比起来，具有更加好的并发性能，他能够有效的避免脏读。但是，其觉得也是很明显的，如会导致虚读、第二类更新丢失等问题。在实际工作中，我们一般可以通过前台程序的控制，如可以在设计应用程序的时候，采用悲观锁或者乐观锁来避免这些问题的产生。

　　如以前我在为一个学校的行政管理系统设计数据库的时候，就是利用这个处理事务的级别与乐观锁结合处理第二类数据更新丢失的问题。乐观锁，虽然有一个锁字，但是其跟对记录加锁不是同一个原理。当用户从数据库查询数据时，不会对数据进行加锁;当用户需要更改这条数据时，则应用程序要先从数据库中进行核对，看看自从自己上次读取了这条记录之后，是否还有其他员工修改了这条记录呢。如果有其他员工修改了这条记录，这个事务通常就会被回滚。这就是应用程序乐观锁跟这个事务处理级别结合起来使用的一个典型例子。在更新数据之前，先花费这个代价并不是很高的检查动作，能够避免第二类数据更新丢失的问题。

　　一般来说，若我们对于数据库的性能要求比较高，则建议采用这种事务隔离方式。因为若对记录加锁处理的话，会对数据库的运行性能产生很大的不良影响。相反，若对数据库的性能要求不是很高，或者说，数据库的性能不会对应用程序的整体性能产生很大影响的话，那么笔者建议还是采用第一种处理方式。如此的话，我们就不需要在应用程序端进行过多的控制。