[C#]公交车路线查询系统后台数据库设计——换乘算法改进与优化

 

公交车路线查询系统后台数据库设计系列文章

数据库下载 (该数据库已经输入了广州市350条公交车路线作为测试数据) 

 

在《查询算法》 一文中已经实现了换乘算法,但是,使用存储过程InquiryT2查询从“东圃镇”到“车陂路口”的乘车路线时,发现居然用了5分钟才查找出结果,这样的 效率显然不适合实际应用。因此,有必要对原有的换乘算法进行优化和改进。在本文中,将给出一种改进的换乘算法,相比原有的算法,改进后的算法功能更强,效 率更优。

1. “压缩”RouteT0

假设RouteT0有以下几行

clip_image002

如下图所示,当查询S1到S4的二次换乘路线时,将会产生3×2×4=24个结果

clip_image004

从图中可以看出,第1段路线中的3条线路的起点和站点都相同(第2、3段路线也是如此),事实上,换乘查询中关心的是两个站点之间有无线路可通,而不关心是乘坐什么路线,因此,可以将RouteT0压缩为:

clip_image006

如下图所示,压缩后,查询结果有原来的24条合并1组

查询结果为:

那么,为什么要对视图RouteT0进行压缩呢,原因如下:

(1)RouteT0是原有换乘算法频繁使用的视图,因此,RouteT0的数据量直接影响到查询的效率,压缩RouteT0可以减少RouteT0的数据量,加速查询效率。

(2)压缩RouteT0后,将中转站点相同的路线合并为1组,加速了对结果集排序的速度。

2.视图GRouteT0

在数据库中,将使用GRouteT0来描述压缩的RouteT0,由于本文使用的数据库的关系图与《查询算法》中有所不同,在给出GRouteT0的代码前,先说明一下:

clip_image009

主要的改变是Stop_Route使用了整数型的RouteKey和StopKey引用Route和Stop,而不是用路线名和站点名。

GRouteT0定义如下: 

create view GRouteT0
as
select 
    StartStopKey,
    EndStopKey,
    
min(StopCount) as MinStopCount,
    
max(StopCount) as MaxStopCount
from RouteT0
group by StartStopKey,EndStopKey

 

注意,视图GRouteT0不仅有StartStopKey和EndStopKey列,还有MinStopCount列,MinStopCount是指从StartStop到EndStop的最短线路的站点数。例如:上述RouteT0对应的GRouteT0为:

clip_image011

3.二次查询算法

以下是二次换乘查询的存储过程GInquiryT2的代码,该存储过程使用了临时表来提高查询效率: 

GInquiryT2

 

4.测试

(1) 测试环境

    测试数据:广州市350条公交车路线

    操作系统:Window XP SP2

    数据库:SQL Server 2000 SP4 个人版

    CPU:AMD Athlon(tm) 64 X2 Dual 2.4GHz

    内存:2G

(2)选择用于测试的的站点

二次换乘查询的select语句使用的三张表#R1,#R2,#R3,因此,这三张表的数据量直接影响到二次换乘查询使用的时间:

显然,R1的数据量由起点决定,查询起始站点对应的#R1的数据量的SQL语句如下: 

select Stop.StopName as '站点',count(StartStopKey) '#R1的数据量'
from RouteT0 full join Stop on RouteT0.StartStopKey=Stop.StopKey
group by Stop.StopName
order by count(StartStopKey) desc

 

运行结果如下:

clip_image013

显然,但起点为“东圃镇”时,#R1的数据量最大,同理可得终点和#R3数据量关系如下:

clip_image015

因此,在仅考虑数据量的情况下,查询“东圃镇”到“车陂路口”所用的时间是最长的。在下文中,将使用“东圃镇”作为起点,“车陂路口”为终点对二次查询算法进行效率测试

(3)效率测试

测试语句如下:

exec GInquiryT2 '东圃镇','车陂路口'

 

测试结果:

查询结果如下:

clip_image017

输出如下:  

测试输出

 

从消息窗口的信息可以看出,查询大概用了1秒

5.效率优化

用GInquiryT2查询“东圃镇”到“车陂路口”仅用了1秒钟,那么,还能不能再优化呢?仔细分析输出的结果,可发现查询时最耗时的并不是换乘查询语句(140ms),而是筛选出第2段查询路线的语句(825ms),如图所示:

clip_image019

那么有没有方法可以提高筛选第2段路线的效率呢?答案是肯定的。只需把GRouteT0改成实表,并创建索引就行了。改成实表后,就不需要把第2段路线缓存到临时表#R2中,修改后的GInquiryT2(重命名为GInquiryT2_1)如下:

GInquiryT2_1

 

下面,仍然用查询“东圃镇”到“车陂路口”为例测试改成实表后GInquiryT2的效率,测试语句如下:

exec GInquiryT2_1 '东圃镇','车陂路口'

 

消息窗口输出如下:

测试输出

 

从输出可以看出,大概用了250ms

6.展开路线组

GInquiryT2查询给出的结果是10组最短路线,那么,怎样才能得到最短的10条路线,显然,只需将这10组路线展开即可(展开后的路线 数>=10),而最短的10条路线必然在展开的结果中。查询10条最短路线的存储过程GInquiryT2_Expand如下: 

GInquiryT2_Expand

下面,仍然以查询“东圃镇”到“车陂路口”为例测试GInquiryT2_Expand,代码如下:

exec GInquiryT2_Expand '东圃镇','车陂路口'

查询结果如下:

消息窗口输出如下:

测试输出

 

由输出结果可看出,大约用了300ms

7.总结

下面,对本文使用的优化策略做一下总结:

(1)使用临时表;

(2)将频繁使用的视图改为表;

(3)从实际出发,合并RouteT0中类似的行,从而“压缩”RouteT0的数据量,减少查询生成的结果,提高查询和排序效率。

作者:

卢春城

转载:http://www.cnblogs.com/lucc/archive/2009/03/03/1401863.html

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏