BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

从数据库查询中寻找设计问题

| 作者 周宇刚 关注 0 他的粉丝 发布于 2014年5月27日. 估计阅读时间: 6 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

在数据库中对数据的操作可以分为两类:查询和命令。由于命令会修改状态(数据),因此会得到开发团队很高的关注。甚至我所在的组织里,对故障的分级也是对此参照的:如果是数据显示错误,则属于轻度故障;如果是数据更新错误,则属于严重故障。但查询并不总是善类,比如在《基于Oracle的SQL优化》一书中,作者曾提到一个案例:优化一个关联了18个表的查询。在赞叹作者高超的SQL调优技术的同时,我不禁想到是否真有必要编写如此复杂的SQL?复杂查询带来可能不仅仅是性能问题,其背后隐藏的还有可能是不恰当的架构和设计。查询应该受到更多的关注。

控制条件查询的复杂度

企业应用程序的开发人员经常和数据库打交道,有时会过于依赖SQL强大的查询能力,随着需求的演化,SQL可能会越来越复杂,难以维护。

通用的条件查询

比如考虑一个酒店预订网站,客户在下单后的30分钟内需要完成支付或是提供信用卡担保,否则系统会自动将订单取消。开发团队使用定时任务来筛选出“过期”的订单:

图表 1 使用SQL条件查询

看上去也挺简单,但是订单作为一个主要的业务对象,会有许多查询的需求,一般都会实现动态条件查询。

图表 2 构造条件查询,要求orderRepository的实现能够动态拼接SQL语句

条件查询虽然好用,但测试起来可不轻松。因为在依赖数据库的自动化测试中准备、清理数据相比单元测试更麻烦。每个测试用例的上下文最好是独立的,这样不容易因为测试用例执行顺序问题导致测试结果不一致。此外,测试数据相互独立对于维护性也很重要,当测试用例达到一定规模时,“复用”测试数据以减小工作量的初衷是好的,但是很容易让测试用例的设计顾此失彼,适得其反。不必要的条件查询和其组合加剧了这个问题。另一方面,随着需求演化,有些查询条件还需要额外关联一些表,比如,现在要求VIP会员不受自动取消过期订单的约束。SQL可能变成了:

图表 3 随着需求演化,SQL开始变得复杂

于是不断有新的条件和关联表被加进来,而测试时要准备的数据也越来越多。在实际项目的iBATIS sqlmap文件中(此处的例子都经过简化),改造前拼接动态查询的篇幅超过了200行,可以根据条件动态关联对应的表,貌似十分“强大”,实际上看起来都很费劲,添加新功能经常导致部分查询的条件拼接不完整,非常痛苦。

查询 “结果”

对于按客户名称搜索订单,还是条件查询比较好用。但对于特定目的,又带有计算的查询就不是那样了。实际上,我们可以把计算的结果用来实现查询,而不是在查询中去计算。开发团队为了解决这个问题,后来改造了下单的过程,计算并保存了订单的截止时间并为其实现了一个专用查询。

图表 4 保存计算的结果,计算在下单时完成,很容易做单元测试

图表 5 查询结果

随着设计的变化,测试策略也相应调整,现在由ApplicationEvents的单元测试来验证关键的业务条件,而查询可能过期订单的测试由于和订单这个“热门”隔离开了,测试的数据准备和清理不容易发生冲突,也变得更为简单。

慎用数据库集成

在实现修改状态的功能时,开发团队往往会定义良好的接口和服务契约来降低构件间的依赖。而在处理查询功能时,开发团队有时会迫不得已使用数据库集成,但这种方式却悄悄地削弱了解耦的努力。

数据来自于两个系统

让我们回到酒店预订网站的例子,现在希望提供住客点评酒店的功能。但为了防止“灌水”,要求对每张订单只能点评一次。

图表 6 订单中心可以点评

在系统实现上,酒店点评是独立于酒店订单的一个应用程序。如果只是在查看订单详情时才显示点评的入口,那么开发团队会很自然地想到通过应用程序集成,比如由酒店点评系统提供一个查询某张订单是否有对应点评的服务。不过若在订单列表就要显示的话,开发团队觉得还是直接使用数据库集成更简单一些,而且还减少通信次数。改造一下订单列表的查询语句,在其中嵌套点评计数的语句:

图表 7 数据库集成

查询“本地”数据

但很快,开发团队发现这也许不是一个明智的主意。一方面,这个方案会增加订单查询的持久化测试用例,而且为了能够部署流水线中运行这些测试,还不得不把本属于酒店点评系统的数据库脚本复制过来。而另一方面,开发团队发现这个方案其实要求两个系统合用一个数据库,或至少使用DBLink才行。这种部署灵活性上的缺陷也给部署流水线的准备带来了不少的麻烦。

图表 8 部署限制

于是,团队调整策略,在t_hotel_res_order上增加了点评数量的冗余字段,而该数据采用消息队列来同步,这样查询就可以在“本地”实现了。

图表 9 使用MOM集成

Fail fast Learn fast

一般来说,一个功能总是可以通过多种方式来实现,除了性能之外,可维护性也是很重要的决策因素。开发团队的经验固然很重要,但尽早开展测试来评估、验证方案往往更科学。

参考实现方案对应的测试方案及成本:如果要为某个查询的测试用例准备5、6个表的数据,那么值得考虑一下是否有查询“结果”的方案。尤其是报表类的功能,非常容易演化成长篇的SQL语句。

参考实现方案对应的部署方案:尽早建立部署流水线,尽早规划部署资源和方案并演练。如果出现不必要的“限制或约束”,那么值得考虑更换集成方案。


感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT