为什么要避免编写复杂的SQL查询 - 以及应该做些什么
2018-12-02
来源:atomic
浏览量:122


BY: ANDY PETERSON

如果您使用过与数据库通信的软件,那么您可能会遇到一个很长的SQL查询。慢慢地,当你试图通过许多连接和子查询推理时,你的眼睛会茫然,试图弄清楚这个查询是否是bug的来源。

你在不同的选择之间进行辩论。您是否应该寻找查询的原始创建者,或者自己重新设计查询,以便有机会了解其隐藏的复杂性?

公平地说,有很多非SQL代码可以引起类似的反应。但是,我开始意识到在代码中嵌入SQL查询可以限制不断发展的代码库。

复杂SQL查询的问题

SQL查询非常适合询问有关一组数据的问题。他们是高效的,熟悉各个项目,总体而言,非常强大。老实说,我最喜欢的软件开发部分之一就是编写复杂的查询。

但是,我注意到了我的项目的一个趋势:SQL查询危险地将软件耦合到持久层。显然,我们需要SQL查询来从我们的数据源中获取数据,但开发人员很容易过度使用它们。

我发现自己在查询中嵌入了关键业务规则,除了他们正常的数据获取责任之外。在大型查询中,业务逻辑可能会被查询的许多移动部分混淆。查询需要定义不同数据片段之间的关系,连接这些表,对结果行进行分组,对结果集进行排序等等。

虽然开发人员可以编写超高效查询来获取数据并应用业务规则,但这种方法对于不断发展的软件来说是不可持续的。随着对业务领域的理解的增长,数据模型不断发展以适应新的发现。但是,您对数据库模式所做的任何更改通常意味着重新工作或完全重新设计查询。有时,我甚至选择不更改数据模型,因为担心在精细系统中重新创建大量SQL查询。

大型SQL查询的替代方法

为了避免嵌入在生产代码中的大型SQL查询的痛苦,我发现了两种选择:

  1. 使用大量小查询。

  2. 使用查询构建器。

第一种选择很简单。而不是旨在使用一个可以一次抓取所有内容的查询来命中数据库,而是考虑将进程分解为更小的位。写一些查询来抓取数据部分,在内存中进行任何处理而不是聚合函数。我发现这种方法对于完全理解问题很有用,而不必跳到最高性能的解决方案。

在使用小型查询时,还值得考虑效率的权衡。小查询往往责任较少,因此可以在更多情况下应用它们。与功能的单一责任原则类似,具有一小部分职责的查询更有可能真正擅长其工作,正确和可测试。

我更喜欢第二个替代方案,它涉及使用查询构建器,我发现在将大型复杂查询分解为描述查询各个方面的小函数方面取得了巨大成功。这为您提供了一组具有共享概念的多个查询。如果您在Node.js中工作,我强烈建议您查看Knex.js以进行查询构建。

最后的想法

复杂的查询在软件开发中占有一席之地 - 有一些问题需要通过性能最高的工具来解决。但是,我觉得将复杂查询分解成更小的位是值得的。较小的查询允许在不断发展的软件中提供更大的灵活性,这通常与性能(有时更理想)一样令人满意。让我知道您在评论中的体验。


标  签: 数据库,软件开发

联系我们

010-84150507
售前服务
技术支持 Service@qeebu.cn
留言