模块化 SQL，即使只是语法糖答案

【问题标题】：Modularizing SQL even if only syntactic sugar模块化 SQL，即使只是语法糖
【发布时间】：2013-01-19 12:27:18
【问题描述】：

有没有办法将 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

Code reuse and modularity in SQL

Are Databases and Functional Programming at odds?

【问题讨论】：

java == 程序？ SQL == 程序错误
呜呜呜！这样做会失去你需要从 SQl 获得的最重要的东西之一，那就是性能。阅读的难易程度无关紧要，重要的是服务器制定一个体面的计划以最有效地获取数据的难易程度。不要试图将 OOP 概念应用于 SQL。（顺便说一句，我发现 SQL 一点也不难调试，如果你这样做了，那么显然你需要更好地学习 SQL，而不是试图抽象它。）
@HLGEM 。 . .实际上，我认为它可以帮助优化器。例如，SQL Server 重新执行对 CTE 的每个引用这一事实，即使该查询给出了 little 提示 CTE 将被多次重用。跨度>

标签： sql abstraction

【解决方案1】：

在大多数数据库中，您可以使用 CTE（通用表表达式）做您想做的事情：

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

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

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

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

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

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

【讨论】：

啊哈，CTE 是我一直在寻找的想法。您直接遇到了问题，即我们越来越多地使用数据库作为我们的主要分析平台，而我们可能用 SAS 编写的探索性/研究数据缩减查询现在正在推送到数据库。完全同意中间表/视图的角色，如果一个人有写权限并且查询值得。
在 PostgresQL 中也称为 'with' 表达式 postgresql.org/docs/9.1/static/queries-with.html，“这些语句..可以被认为是定义了仅用于一个查询的临时表。”

【解决方案2】：

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

【讨论】：