SQL查询的心智模式

Question

在准备SQL入门材料时，我结束了对开发人员编写查询时所遵循的思路的询问。从初学者的角度来看，我认为它可能太有价值了。

让我举一个例子来说明这个问题。为了简洁起见，我将不包含数据库模式，希望查询本身具有足够的描述性。

假设我们想要编写一个查询，用于检索最后一个季度的所有新客户。典型的。我首先想到的是所涉及的一组实体，首先是与所请求的数据相对应的实体。因此，由于我想获得客户，首先我编写了以下查询框架：

    SELECT
      FROM Customers AS NewCustomer
     WHERE 

立即跟踪剩下的实体。在这种虚构的背景下，新客户是第一次下订单的任何客户：

    SELECT
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
 LEFT JOIN Orders AS OlderOrder
     WHERE 
       AND OlderOrder.Id IS NULL

在确定了所有实体之后，我开始写它们之间的关系：

    SELECT
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
        ON RecentOrder.CustomerId = NewCustomer.Id
 LEFT JOIN Orders AS OlderOrder
        ON OlderOrder.CustomerId = RecentOrder.CustomerId
       AND OlderOrder.PlacementDate < RecentOrder.PlacementDate
     WHERE 
       AND OlderOrder.Id IS NULL

一旦我完成了实体的处理，就该定义对结果数据集应用的任何限制了：

    SELECT 
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
        ON RecentOrder.CustomerId = NewCustomer.Id
 LEFT JOIN Orders AS OlderOrder
        ON OlderOrder.CustomerId = RecentOrder.CustomerId
       AND OlderOrder.PlacementDate < RecentOrder.PlacementDate
     WHERE RecentOrder.PlacementDate BETWEEN @fromDate AND @toDate
       AND OlderOrder.PlacementDate < @fromDate
       AND OlderOrder.Id IS NULL

最后，我问自己希望查询返回哪些具体数据字段，从而完成SELECT子句：

    SELECT NewCustomer.FirstName, NewCustomer.LastName
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
        ON RecentOrder.CustomerId = NewCustomer.Id
 LEFT JOIN Orders AS OlderOrder
        ON OlderOrder.CustomerId = RecentOrder.CustomerId
       AND OlderOrder.PlacementDate < RecentOrder.PlacementDate
     WHERE RecentOrder.PlacementDate BETWEEN @fromDate AND @toDate
       AND OlderOrder.PlacementDate < @fromDate
       AND OlderOrder.Id IS NULL

当然，这是一个非常简单的查询，没有聚合、嵌套查询和其他高级内容。但这是我的总体思路，不管查询的复杂性如何：

1. 实体
2. 关系
3. 限制
4. 字段

我的问题是，对于初学者来说，这是一个适合明确学习的模式吗？无论如何，为了使她的学习曲线平滑，怎么能改进呢？

Answer 1

tl；

博士

我想你把它倒过来了。

一个知识渊博的开发人员按照这里提到的顺序构建他的查询，因为这是依赖关系的顺序--在您知道您需要哪些实体之前，您不知道需要遵循什么样的关系；在不首先确定您的关系之前，您不知道需要什么限制；在您知道您可以使用的字段集之前，您不知道应该限制什么。

因此，一个知识渊博的开发人员经常会按照设定的顺序进行开发，因为在现实世界中，我们需要最高级别的组件--实体--以及该部分驱动我们如何使用其他组件。

但是，此顺序是从最高级别最受抚养人到最低级别最小受抚养人件。对于不熟悉SQL的人来说，当实体还不知道关系、限制或字段时，你不想先教他们；过渡性地，你不应该教那些不知道限制或字段的人，或者不知道字段的人。

考虑到你在上面详述的概念，以及我对它的理解，你应该按照你所建议的那样，以相反的顺序来教他们。

我认为，如果您查看上面的示例查询，就会发现这一点很明显--要查询概念实体，最终得到的查询要比新的SQL开发人员首先应该查看的要复杂得多。此外，直到最后一段您还没有完成SQL查询，因为您最后要教的是其他每个片段都需要的最依赖的部分。您建议这样做的方式是，在您完成所有概念的教学之前，应该像上面那样给出不完整的SQL示例，给出更小、更复杂而不是更完整的示例似乎更合理。