一个算法：用来确定每次选择多少行来构建Sql语句，相当于SqlDataAdapter的UpdateBatchSize属性。要能做到记录行不是整数倍的UpdateBatchSize的时候 能够将剩余的也能组合起来。
UpDate的算法：要研究一下DbDataAdapter的Update方法的原理，以及它的重载方法之间的联系。Update数据的话不能永远都去构造Update语句。应该是有高级一点的方法的。需要花时间找出来。
对于数据库的更新操作要去看看微软的EntLib的相关处理。
关于自己弄的数据库读写类，需要添加一些常用的方法，目前的方法太少了点，要支持更多的操作，为此要将原有的方法弄透彻，再按照原有思路去加上新的一系列的方法。需要考虑的不仅仅是简单的对数据库的读写，还要做数据库中表对表的，数据库之间表对表的数据的交互，要考虑好性能问题。让数据库之间大量数据的读写，更新快起来。
数据库读写类也可以参考微软的EntLib，看能不能在它的基础上扩展，DAAB估计不是很好往其他更多的数据库上面扩展，微软的官方的可能在安全性和性能上面都还是不错的，要自己写的话要参考一下，考虑一下相关的性能和安全方面的参数问题。
新的这个数据库读写的类觉得在单独对数据库的操作的话，在性能上应该是比以前的EgovDataBase要好些，至于要好多少就要看我的功夫了，希望能更上一层楼。总觉得得弄一个至少是.net 2.0级别的数据库读写类出来，不能总用老方法啊，要用一些新特性看看。System.Data.Common里面的DbProviderFactories这个是一个不错的选择。至少算是官方的用于兼容多个数据库操作封装出来的。值得参考。
而且好像EnterpriseLibrary里面的东西不好单独拿出来用，要用就是一整套庞大的类库，确实不是很方便啊。还有日志的考虑，是直接用人家的那个Longbow.ExceptionManagement.dll还是自己重写一个？我觉得它这个用来记录异常还是很不错的，但是要是用来写一些日志类信息，好像就不行了。因为它好像只能处理异常，要不就自己定义一大堆异常，包括一些日志的信息，然后再交给它处理。关于自定义的异常还需要测试，它能不能很好的处理出正确的信息。
复杂的大量数据的操作，可以考虑下异步的数据读取，为了不影响主进程。考虑性能问题，添加事务处理，但是开关事务要自己决定，给程序员最大限度的自由，--不能培养傻瓜型程序员。事务开启后的处理应该要更加快速。而且程序员应该考虑到那些处理可以用事务，那些需要实时的显示结果信息的不能用事务。