15

有没有办法将 SQL 代码模块化,使其更具可读性和可测试性?

我的 SQL 代码经常变成一长串复杂的嵌套连接、内连接等,难以编写和调试。相比之下,在像 Javascript 或 Java 这样的过程语言中,人们会将离散的元素作为单独的函数捏出来,你可以按名称调用。

是的,可以将每个查询编写为完全独立的查询,存储在数据库中或存储过程,但通常我不想更改/混乱数据库,只需查询就可以了,特别是如果 DBA 不希望授予所有用户写入权限。

例如,从概念上讲,一个复杂的查询可能很容易用伪代码描述,如下所示:

(getCustomerProfile) 
left join 
(getSummarizedCustomerTransactionHistory) 
using (customerId) 
left join
(getGeographicalSummaries) 
using (region, vendor)
...

我意识到从理论上的优势(下面有几个链接)写了很多关于这个主题的文章,但我只是在寻找一种方法来使代码更容易正确编写,并且在编写后更容易阅读。也许只是语法糖来从视觉中抽象出复杂性,如果不是从执行中抽象出来,它会在我试图不看的文字 SQL 中编译下来。类推...

  • 手写笔:CSS ::
  • CoffeeScript : Javascript ::
  • SAS 宏语言: SAS 语言 ::
  • ? : SQL

如果特定的 SQL 风格很重要,我的大部分工作都在 PostgresQL 中。

http://lambda-the-ultimate.org/node/2440

SQL 中的代码重用和模块化

数据库和函数式编程有矛盾吗?

4

2 回答 2

6

在大多数数据库中,您可以使用 CTE(通用表表达式)做您想做的事情:

with CustomerProfile as (
      getCustomerProfile
     ),
     SummarizedCustomerTransactionHistory as (
      getSummarizedCustomerTransactionHistory
     ),
     GeographicalSummaries as (
      getGeographicalSummaries
     )
select <whatever>

这适用于单个查询。它的优点是您可以定义一次 CTE,但可以多次使用它。此外,我经常定义一个const具有常量值的 CTE。

下一步是采用这些结构并从中创建视图。这在多个模块之间共享代码时特别有用,以确保常量定义。在某些数据库中,您可以在视图上放置索引以“实例化”它们,从而进一步优化处理。

最后,我建议在存储过程中包装插入/更新/删除。这使您可以拥有一个一致的框架。

不过还有两条评论。首先,SQL 通常用于事务或报告系统。通常,一旦您为目的获得了正确格式的数据,数据就说明了一切。您的示例可能只是要求一个数据集市,其中包含三个专门用于这三个主题领域的表,这些表每周或每天填充一次。

而且,SQL 不是抽象的思想语言。通过良好的实践、命名约定和缩进样式,您可以使其变得有用。我非常想念“真实”语言中的某些东西,例如宏、错误处理(为什么数据错误如此难以识别和处理超出了我的范围)、通用功能的一致方法(有人可以说组字符串连接)和其他一些特征。也就是说,因为它以数据为中心并且易于并行化,所以它对我来说比大多数其他语言更有用。

于 2013-02-04T18:48:29.777 回答
1

这里的问题是您需要以关系的方式考虑数据。我不相信这种类型的抽象正确地适合关系模型。就使 SQL 模块化而言,这就是存储过程和/或函数的用途。请注意它们如何具有与 Java 中的方法相同的特征。你可以这样抽象出来。另一种方法是将您关心的数据抽象为物化视图。通过这样做,您可以在这些物化视图之上放置一个常规视图(参见虚函数),这允许您在不触及“原始”表的情况下测试数据结构。

于 2013-02-04T18:24:17.050 回答