数据库中可以存储实体的数据集合,在进行运算时,数据库使用批量计算的方法来处理数据,批量的从存储设备上读取数据,处理之后又批量的写回存储设备。有的数据库提供了游标,游标可以读取出表中一行的数据中的每一个字段,对这些字段进行复杂的业务规则计算,然后再写回数据库中。与使用批量的方法比较,批量计算的方法消耗的资源相对比较少,而使用游标则占用太多的资源,速度比较慢,效率较低并且还有加锁条件等许多的限制。
2.依次批量更新数据库,把所有的level字段的值设置为D,再次更新数据库,把成绩大于等于60的纪录的Level字段更新为C,依次更新B、A。这样做的一个缺点是有些纪录的Level字段被更新多次,比如一个记录最后的Level字段的值是A,则它首先被更新为D,依次被更新为C、B、A。这些重复的更新是可以被消除的,把算法改进一下就可以省去重复更新的花费。更新后的算法是这样的,把成绩介于0和60分的纪录的Level字段更新为D,依次更新各个分数段的成绩。实现的这种算法的SQL语句并不难写出,使用 Between…and…表达式即可以表达例如介于80到90之间纪录的选择条件。
3.鉴于第二种方法最后的分析,使用between…and…表达式同时参照一个表来更新纪录,则可以方便表达分数段与相应的level信息,把这些信息存储到一个表level_about中,在更新student_score表的过程中可以参照这个表。计算的过程中,需要把level_about表的内容读出来,然后进行计算。对于整个计算过程来说,牺牲空间和部分效率来换来操作方便,,由于现在计算机的速度相当快,level_about表占用的空间又很小,这方面的损失可以忽略不记。Level_about表中的信息至少包含3 个字段:start_score,记录起始分数,end_score记录终止分数,level记录介于起始分数和终止分数之间的分数应该得到的成绩。表中的数据应该类似于这样:
|
更新student_Score表中的纪录需要依据Start_score和End_score来判断当前记录中成绩所在的Level,在Mssql中实现的SQL语句:
|
比较以上3种方法,实现同一个目的采用不同的算法实现的效果是不同的。
业务需求是每周一和周四结算奖金,不难发现奇数次结算依次相差7天,偶数次结算依次相差7天,相邻奇数次和偶数此结算相差3天,可以使用求余的方式来统一这个问题。如果当前天数(days)与7求余结果为0或者当前天数 (days)减去3之后求余的结果为0,则当前天数是结算的日期。具体的实现的算法是:
1、提取当前的天数到一个变量中declare @days int set @days=(select days from misc)
2、判断是否满足结算条件if @days%7=0 or (@days-3)%7=0 begin…end
类似于这样简单的算法可以直接的应用到数据库中而不会发生问题。
复杂的业务规则需要复杂的算法,复杂的规则对于一个有具体数字的变量来说,实现起来已经比较复杂,如果应用到数据库中存储的杂乱无章的一大批数字,并且实现批量的计算,则需要对算法进行大幅度的调整。
比如业务规则需要在员工每4000元的奖金中扣除400元作为重复消费,并且在扣除最后的400元,重复消费一次奖励一件产品,需要在数据库中使用一个表(award_repeat)记录产生的重复消费。如果一次扣除的奖金不足400 元,在下次结算的时候接着扣除,直到扣除的奖金够400元,然后奖励一件产品,进入下次的循环,比如现在奖金总数达到了3600元,则不会扣除,如果达到了3700元,则要扣除100元,如果达到了7700元,则要扣除410元,并且产生一个重复消费。
为了实现这个规则,在员工表(member)中记录每个员工奖金的总数([total_award]),同时记录重复消费的次数([repeat_num]),在另外的过渡表(award_day)中记录每次的奖金和每次扣除重复消费的奖金,最后在奖金表(award)中综合当次奖金和当次结算需要扣除的重复消费就得到了当次结算实际发放的奖金。采用批量的计算方法,实现的算法是:在计算奖金之后,扣除重复消费之前把当前奖金累加到员工的([total_award])字段([total_award]),记录没有扣除重复消费的所有的奖金总和。实现重复消费计算的的算法是,设定条件(F1)为在member表中存在奖金总数大于等于重复消费次数加1后乘以4000,如果有满足条件F1的记录,则选择满足条件的纪录中主键和当前的日期(days)插入到重复消费表(award_repeat)中,然后更新member表中满足条件F1的repeat_num使其增加1,重复检查条件F1,直到member表中没有满足条件F1纪录。