即使只是语法糖,模块化SQL

Question

有没有办法模块化SQL代码,以便更具可读性和可测试性？

我的SQL代码经常变成一系列复杂的嵌套连接,内部连接等,难以编写且难以调试.相比之下,在诸如Javascript或Java之类的过程语言中,人们会将离散元素作为单独的函数来捏合,这些函数将按名称调用.

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

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

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

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

• 手写笔:CSS ::
• CoffeeScript:Javascript ::
• SAS Macro语言:SAS语言::
• ？:SQL

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

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

SQL中的代码重用和模块化

数据库和功能编程是否存在争议？

Answer 1

在大多数数据库中,您可以使用CTE(公用表表达式)执行您想要的操作:

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

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

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

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

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

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