关于开发BugTiger的想法(3)

决定把原来的BugRaid改名为BugTiger

注:本文中出现的更新是指Smart Client中的客户端通过WebServices来读取数据,而不是指数据库中数据的更改.

        最近对TaskVision(以下简称TV)和IssueVision(以下简称IV)进行了学习,对两者的数据处理方式进行了对比.结合两者的特点谈一下自己对BugTiger的一些想法.

       首先是数据读取的问题.

       在TV中,Client每次都读取某个Project的所有Tasks数据,不去判断是否为修改过的数据;在IV中,Client有一个变量来记录上次更新的时间,每次请求更新时把这个更新时间作为参数传递给WS,然后比较数据表的DateModified来决定哪些数据是新的,需要Client进行更新.

       对这两种方式进行简单的比较,TV的实现比较简单,但是缺点也是明显的,有一部分读取的数据是重复的,如果表中记录数比较多的情况下是不可取的.而IV里的实现方式不用每次返回所有数据,只要返回修改过的数据给Client,减少了Server的负担,也减少了网络传输的负担.IV这种方式的和TV相比,客户端需要对原来的数据和新取得数据进行处理(合并),增加了客户端的编程复杂性.在IV中假设了只有DBA能删除数据(物理删除),这种方式才能使用.对于一个客户端也可以进行删除数据(物理删除)操作的Smart Client,这种方式就存在一个问题.当有用户删除了数据后其他客户端不会知道哪条数据被删除了,无法对数据就进行同步,在其他的用户里还是存在被删除的记录.

        分析了这两种数据更新的方式之后,我谈一下对BugTiger中实现数据读取的看法

        建立一张额外的UpdateInfo表来记录其他表最后修改时间. UpdateInfo表的主要部分结构如下

       TableName NVARCHAR(20) 表名.
       ModifiedDate DateTime  最后更新时间,表中的记录最后修改时间. 

       客户端同步数据时提供上次更新的时间(LastUpdatedDate),然后比较UpdateInfo每个表的ModifiedDate来确定哪些表需要更新. 当数据库的表中记录发生改变时,对UpdateInfo表进行更新.这样就确定了哪些表需要进行更新,接下来我说一下如何进行表的更新.

        我将表分为两类,一类是大表,即数据记录数比较多的,需要经常更新的,如Bug表(用于记录Bug的信息),BugComment表(记录用户对Bug的评论),对于这类表我考虑采用IV的方式,采用部分更新的方法,即每次只更新自上次同步后被修改过( Update ,Create)的记录.

每条记录都用一个ModifiedDate来记录最后更新时间,Client的上次更新的时间(LastUpdatedDate)和ModifiedDate进行比较来决定哪些数据需要更新.还有一类小表,不需要经常更新,数据量又不是很大的,如BugPriority(Bug的优先级),ProjectModule(项目的模块),这些表数据量不是很大,而且这些数据不需要经常更新.对于这类表采用TV的方式,只要有一条数据被修改就更新整张表的方式来进行(这样做在实现上比较简单).

        第二要考虑的就是数据冲突的问题

       在TV和IV里都用通过捕捉异常的方式来进行数据冲突检测.在更新操作过程中受影响的行数等于零时，由 DataAdapter 引发DBConcurrencyException 异常 。SQL语句里把客户端的原数据作为条件传入,客户端的原数据和DB中的数据进行比较,如果不一致,说明在读取这条数据和更新这段时间间隔内已经有人更改了数据,发生冲突.这样如果数据更新引发DBConcurrencyException .我觉得可以在存储过程中返回@@rowcount.