HW 6：SQLok 4 项通过

0. 这份作业在练什么

前面五份作业你一直在做同一件事：写一个函数，告诉计算机怎么一步一步算出答案。递归、循环、链表遍历，本质都是「指挥机器按什么顺序动」。这种写法叫命令式编程（imperative programming）。

SQL 把这件事整个掀翻了。写 SQL 的时候，你不描述步骤，只描述你要的那张表长什么样。「给我一张表，它的每一行是一只有父母的狗的名字，按父母身高从高到矮排」——你说完这句话就完事了，至于数据库内部是先扫 parents 还是先扫 dogs、是用嵌套循环还是用哈希索引，全部不归你管。这种写法叫声明式编程（declarative programming）。

所以做这份作业最大的障碍不是语法——SQL 的语法两页纸就讲完了——而是思维方式的切换。绝大多数初学者卡住的瞬间，都是因为脑子里还在想「我先遍历 parents，对每一行去 dogs 里查一下……」。这个念头一旦冒出来，你就会想去找 SQL 的 for 循环，然后发现没有，然后卡死。

本页会反复用同一个心法帮你脱困：把 FROM a, b 想象成「先把 a 的每一行和 b 的每一行两两配对，摊成一张巨大的宽表」，然后 WHERE 从这张宽表里划掉不要的行，SELECT 从剩下的行里挑出要的列。这个「先摊平、再筛选、再投影」的三步模型，能解释这份作业里的每一道题，包括最吓人的自连接（self join）。

做之前你该已经会的

不多，但都是硬要求：

三张原始表

整份作业只围绕这三张表转，建议你把它们抄在纸上放旁边。hw06.sql 开头这段是官方给的，不许改：

CREATE TABLE parents (parent TEXT, child TEXT);

INSERT INTO parents VALUES
  ('ace', 'bella'),
  ('ace', 'charlie'),
  ('daisy', 'hank'),
  ('finn', 'ace'),
  ('finn', 'daisy'),
  ('finn', 'ginger'),
  ('ellie', 'finn');

CREATE TABLE dogs (name TEXT, fur TEXT, height INTEGER);

INSERT INTO dogs VALUES
  ('ace',     'long',  26),
  ('bella',   'short', 52),
  ('charlie', 'long',  47),
  ('daisy',   'long',  46),
  ('ellie',   'short', 35),
  ('finn',    'curly', 32),
  ('ginger',  'short', 28),
  ('hank',    'curly', 31);

CREATE TABLE sizes (size TEXT, min INTEGER, max INTEGER);

INSERT INTO sizes VALUES
  ('toy',      24, 28),
  ('mini',     28, 35),
  ('medium',   35, 45),
  ('standard', 45, 60);

把 parents 画成家谱会清楚很多（箭头指向孩子）：

ellie(35)
  └── finn(32)
        ├── ace(26)
        │     ├── bella(52)
        │     └── charlie(47)
        ├── daisy(46)
        │     └── hank(31)
        └── ginger(28)

括号里是身高。注意两件事：一，ellie 自己没有父母，所以她不会出现在 Q1 的结果里；二，家谱里的「身高」和「辈分」完全无关——bella 是辈分最低的，却是全场最高的狗（52）。这不是巧合，是出题人故意的，专门用来抓那些把 ORDER BY height 写成按孩子身高排的人。

1. Q1 by_parent_height：第一次连接两张表

题目要什么

官方原话：

Create a table by_parent_height that has a column of the names of all dogs that have a parent, ordered by the height of the parent dog from tallest parent to shortest parent.

翻成人话，拆成三个独立的要求：

期望输出（来自 hw/hw06/tests/by_parent_height.py，这是评分器真正会比对的东西）：

sqlite> SELECT * FROM by_parent_height;
hank
finn
ace
daisy
ginger
bella
charlie

边界情况有两个，都必须想清楚：

第一，同一个父母有多个孩子时，这些孩子的相对顺序无所谓。finn 的三个孩子 ace、daisy、ginger 的父母身高都是 32，它们三个谁在前谁在后题目都认。题面明确写了「The names of dogs with parents of the same height should appear together in any order」。但——注意这个「但」——评分器 by_parent_height.py 里写着 'ordered': True，意思是它会严格按行比对。所以虽然理论上任意顺序都对，实际上你得跟评分器给的那个顺序一致才能过。好消息是：只要你用了下面这种最自然的写法，sqlite 会保持原表的插入顺序，结果自然就是 ace, daisy, ginger，和期望一致。

第二，一只狗如果有两个父母，会出现两次。本次数据里每只狗只有一个父母，所以不会撞上，但你写的查询逻辑必须是「按 parents 表的行来产出结果」，而不是「按 dogs 表的行来产出结果」——这两种写法在有两个父母的数据上会给出不同答案，题面也说了「Your queries should still perform correctly even if the values in these tables change」。

怎么想到的

先摆清困境：我要的信息分散在两张表里。

• 「谁是谁的孩子」在 parents 表里；
• 「某只狗多高」在 dogs 表里。

光看 parents，我知道 hank 的父母是 daisy，但我不知道 daisy 多高。光看 dogs，我知道 daisy 是 46，但我不知道她是谁的父母。要排序，我必须让「孩子的名字」和「父母的身高」出现在同一行上。

这一步是所有 SQL 题的共同起点，记住这句话：凡是需要把两张表的信息凑到一行上的，就是要连接。

第一个念头（错的，但值得走一遍）

刚学完 Python 的人第一反应通常是这样：

# 脑子里的伪代码
result = []
for parent, child in parents:
    h = 去 dogs 里查 parent 的 height
    result.append((child, h))
result.sort(key=lambda t: -t[1])

然后你打开 SQL 手册找 for，找不到；找「查表函数」，也找不到。卡住。

脱困的关键是意识到：SQL 里没有「查」这个动作，只有「配对然后筛」。上面那段伪代码里的「去 dogs 里查 parent 的 height」，在 SQL 里的等价说法是：「把 parents 的每一行和 dogs 的每一行都配一遍，然后只留下那些 parent 恰好等于 name 的配对」。

关键一步：先摊平，再筛选

想通这一点，剩下的就是填空：

第 4 步有个容易漏的认知：ORDER BY 用的列不需要出现在 SELECT 里。我们 SELECT 的只有 child 一列，但排序时仍然能用 height。原因是执行顺序：SQL 先做 FROM（摊平）→ WHERE（筛行）→ 此时中间结果里五列俱全 → ORDER BY（排序，能看到全部五列）→ 最后才 SELECT（挑列，把不要的列丢掉）。排序发生在丢列之前。

代码

-- All dogs with parents ordered by decreasing height of their parent
-- Join parents with dogs so that each child sits next to its parent's height,
-- then sort by that height, tallest parent first.
CREATE TABLE by_parent_height AS
  SELECT child FROM parents, dogs
    WHERE parent = name
    ORDER BY height DESC;

逐行说明：

验证：手动跑一遍

不摊完 56 行，只把 WHERE parent = name 筛剩的 7 行列出来。对 parents 的每一行，找到 dogs 里名字等于 parent 的那一行，把 height 抄过来：

接着 ORDER BY height DESC，按最后一列从大到小重排：

顺便注意验证过程中的一个反直觉之处：bella 身高 52，是全场最高的狗，却排在最后一行；hank 身高只有 31，却排第一。这正是因为排序看的是父母的身高。如果你的输出是 bella 开头，说明你写的是 WHERE child = name——把连接条件搞反了。

2. Q2 size_of_dogs：连接条件不一定是等号

题目要什么

造一张两列的表 size_of_dogs：第一列是狗名，第二列是它的体型分类。分类规则来自 sizes 表，题面给的定义是：

a dog must be over the min and less than or equal to the max in height to qualify as size.

这句英文的边界必须一个字一个字抠：

也就是说，每个体型是一个左开右闭区间 \((\text{min}, \text{max}]\)。这不是吹毛求疵——看 sizes 表的四行：

相邻两行的边界是重叠的：toy 的 max 是 28，mini 的 min 也是 28。如果两边都用闭区间（height >= min AND height <= max），那么身高恰好 28 的 ginger 会同时属于 toy 和 mini，输出里就会多出一行。这份数据里有两只狗踩在边界上（ginger 28、ellie 35），是出题人埋的地雷。左开右闭正好保证每个身高落进恰好一个区间。

评分器（hw/hw06/tests/size_of_dogs.py）实际查的是：

sqlite> SELECT name FROM size_of_dogs WHERE size="toy" OR size="mini";
ace
ellie
finn
ginger
hank

它只验证 toy 和 mini 这两类——正好是边界最密集的地方。ellie(35) 必须是 mini 而不是 medium，ginger(28) 必须是 toy 而不是 mini。区间开闭写反了，这条测试立刻挂。

怎么想到的

Q1 已经建立了「凡是要把两张表的信息凑一行，就连接」的直觉。这题同样是两张表：狗名和身高在 dogs，分类和区间在 sizes。所以骨架一定是 SELECT ... FROM dogs, sizes WHERE ...。

唯一的新东西在 WHERE 里。Q1 的连接条件是 parent = name——一个等号。这里没有任何一对列是「相等」关系：狗表里没有 size 列，尺寸表里也没有狗名。那怎么连？

卡壳点与突破

很多人在这里会想去找一个「区间查找函数」，或者退回 Python 思维写一堆 CASE WHEN height <= 28 THEN 'toy' WHEN ...。后者能跑出正确答案，但它把 sizes 表的内容硬编码进了查询——题面明确警告「Your queries should still perform correctly even if the values in these tables change」，sizes 表加一行 ('giant', 60, 80) 你的查询就废了。

突破口是重新读一遍笛卡尔积的定义：WHERE 后面跟的是任意布尔表达式，没人规定它必须是等号。

把 FROM dogs, sizes 摊平后是 8 × 4 = 32 行，每一行形如「某只狗 × 某个体型类别」，五列：name, fur, height, size, min, max。现在问题变成：这 32 个「狗-类别」配对里，哪些是成立的？答案直接就是题面那句话：height > min AND height <= max。

剩下就是 SELECT name, size——题目说「two columns, one for each dog's name and another for its size」，顺序是名字在前、尺寸在后。

代码

-- The size of each dog
-- A dog matches a size class when min < height <= max.
CREATE TABLE size_of_dogs AS
  SELECT name, size FROM dogs, sizes
    WHERE height > min AND height <= max;

再强调一次为什么 min 和 max 不用加表前缀：这两个名字只在 sizes 表里出现，height 只在 dogs 表里出现，没有歧义。（顺带一提，min/max 和聚合函数 MIN()/MAX() 同名，但 sqlite 靠有没有括号区分，这里当列名用是安全的。）

验证：手动跑一遍

不列全 32 行，只逐狗判断它落在哪个区间。判断方法：对每只狗，扫过 sizes 的四行，看 min < height <= max 是否成立。

最终 size_of_dogs 是 8 行：

ace|toy
bella|standard
charlie|standard
daisy|standard
ellie|mini
finn|mini
ginger|toy
hank|mini

评分器只查 toy 和 mini 的名字，即 ace, ellie, finn, ginger, hank——与期望输出完全一致。

3. Q3 siblings 与 sentences：自连接与字符串拼接

题目要什么

官方定义：兄弟姐妹（siblings）是「有同一个父母」的一对狗。要造一张表，每一行是一个「体型分类相同的兄弟姐妹对」，只有一列，内容是一句描述这对狗的话。

期望输出（hw/hw06/tests/sentences.py）：

sqlite> SELECT * FROM sentences;
The two siblings, bella and charlie, have the same size: standard
The two siblings, ace and ginger, have the same size: toy

题面追加了三条硬性约束，每一条都对应一个必须写进 SQL 的条件：

还有一条隐含要求：只保留体型分类相同的那些对。ace(toy) 和 daisy(standard) 虽然是兄妹，但尺寸不同，不进结果。

题面给了一个可选但强烈建议的中间步骤：先造一张 siblings 辅助表，只存名字对，再用它去造 sentences。这个建议应该听——把「配对」和「造句」拆成两步，每一步都简单到能一眼看懂。

怎么想到的（一）：兄弟姐妹为什么要自连接

先问最朴素的问题：「有同一个父母」这件事，在哪张表里能看出来？

parents 表长这样：

「bella 和 charlie 是兄妹」这个信息，藏在第 1 行和第 2 行的关系里：它们的 parent 列都是 ace。关键认识来了——这个信息不在任何单独一行里，它跨越两行。

而 SQL 的 WHERE 只能对一行做判断。你没法写「这一行的 parent 等于上一行的 parent」，SQL 里根本没有「上一行」的概念。

卡壳与突破

这就是本次作业最大的一道坎。突破的思路是：如果我想同时看到两行，那就让这两行变成同一行。

怎么变？回到笛卡尔积。FROM parents, parents——把 parents 表和它自己做笛卡尔积，得到 7 × 7 = 49 行，每一行装着两条「父母-孩子」记录。这样一来，「第 1 行和第 2 行」这对组合，就成了 49 行里的某一行了。这个操作叫自连接（self join）。

但立刻有个技术问题：两份拷贝的列名一模一样，都叫 parent 和 child。写 WHERE parent = parent 是废话（永远为真）。必须给两份拷贝起不同的名字，这就是题面 Hint 说的「If you join a table with itself, use AS within the FROM clause to give each table an alias」。

写成 FROM parents AS a, parents AS b，之后就能用 a.parent、a.child、b.parent、b.child 分别指代左边那份和右边那份。「同一个父母」的条件就是 a.parent = b.parent。

怎么想到的（二）：a.child < b.child 这一招

加上 WHERE a.parent = b.parent 之后，49 行剩下多少？按父母分组算：ace 有 2 个孩子贡献 2×2=4 行，daisy 1 个孩子贡献 1 行，finn 3 个孩子贡献 3×3=9 行，ellie 1 个孩子贡献 1 行，共 15 行。列出来：

15 行里只有 4 行是想要的。要干掉两类垃圾：

第一个念头是加 AND a.child != b.child，这确实杀掉了「自己配自己」的 6 行，剩 9 行。但 (bella, charlie) 和 (charlie, bella) 都还在，重复问题没解决。于是你会想：怎么在两个方向里只留一个？

第二个念头可能是「用 DISTINCT」。不行——DISTINCT 只能去掉完全相同的行，而 (bella, charlie) 和 (charlie, bella) 是两个不同的行，它管不着。

正确的招：把 != 换成 <，写 AND a.child < b.child。

剩 4 行，正是想要的：(bella, charlie)、(ace, daisy)、(ace, ginger)、(daisy, ginger)。给这两列起个名字 first 和 second，方便下一步引用。

怎么想到的（三）：从名字对到句子

现在 siblings 表有了 4 行名字对。要造句，还缺两样：每只狗的尺寸（用来筛「尺寸相同」并填进句子），以及拼字符串的办法。

尺寸从哪来？Q2 已经造好了 size_of_dogs 表。之前的题目造的表，可以直接当积木用——这是这道题设计成四小问的用意。

但这里有个新的绕：一行 siblings 有两只狗，我需要查两次尺寸。SQL 里没有「查」，只有连接。所以要把 size_of_dogs 连接进来两次——又是自连接的场景，同样要起别名。用 x 查 first 的尺寸，用 y 查 second 的尺寸：

FROM siblings, size_of_dogs AS x, size_of_dogs AS y
WHERE first = x.name AND second = y.name

三张表并列在 FROM 里，笛卡尔积是 4 × 8 × 8 = 256 行，WHERE 的两个等号把它锁回 4 行——每行现在同时有 first、second、x.size（first 的尺寸）、y.size（second 的尺寸）。

然后加上「尺寸相同」的条件：AND x.size = y.size。

最后是拼字符串。题面 Hint 三写了：|| 是连接运算符。注意 SQL 里的 + 是数字加法，不是字符串拼接——写 "a" + "b" sqlite 会试图把两个字符串转成数字，得到 0。必须用 ||。

目标句子：The two siblings, bella and charlie, have the same size: standard。把它切开，哪些是固定的、哪些是变的：

"The two siblings, "  ← 固定
first                 ← 变（bella）
" and "               ← 固定
second                ← 变（charlie）
", have the same size: "  ← 固定
x.size                ← 变（standard）

用 || 依次串起来即可。逗号、空格、冒号一个都不能错——评分器是按整个字符串精确比对的。特别留意："The two siblings, " 末尾有一个空格，" and " 前后各有一个空格，", have the same size: " 开头是逗号、末尾冒号后有一个空格。

代码

-- [Optional] Filling out this helper table is recommended
-- Join the parents table with itself on the shared parent. Requiring
-- a.child < b.child both skips pairing a dog with itself and keeps only
-- one of the two orderings of each pair (alphabetically first name first).
CREATE TABLE siblings AS
  SELECT a.child AS first, b.child AS second
    FROM parents AS a, parents AS b
    WHERE a.parent = b.parent AND a.child < b.child;

-- Sentences about siblings that are the same size
-- Look up each sibling's size, keep pairs whose sizes agree, then build
-- the sentence with the string concatenation operator ||.
CREATE TABLE sentences AS
  SELECT "The two siblings, " || first || " and " || second ||
         ", have the same size: " || x.size
    FROM siblings, size_of_dogs AS x, size_of_dogs AS y
    WHERE first = x.name AND second = y.name AND x.size = y.size;

验证：手动跑一遍

先跑 siblings。FROM parents AS a, parents AS b 摊出 49 行，WHERE a.parent = b.parent 剩 15 行（上表已列），再加 a.child < b.child：

再跑 sentences。把 Q2 算出的尺寸填进这 4 行：

第 1 行：first=bella, second=charlie, x.size=standard
  "The two siblings, "  ->  The two siblings,
  || first              ->  The two siblings, bella
  || " and "            ->  The two siblings, bella and
  || second             ->  The two siblings, bella and charlie
  || ", have the same size: "
                        ->  The two siblings, bella and charlie, have the same size:
  || x.size             ->  The two siblings, bella and charlie, have the same size: standard

第 2 行：first=ace, second=ginger, x.size=toy
  最终                  ->  The two siblings, ace and ginger, have the same size: toy

两行输出与 tests/sentences.py 里的期望逐字符相同。该测试的 'ordered' 是 False，两行谁前谁后都行。

4. Q4 low_variance：分组、聚合与 HAVING

题目要什么

这题的题面绕了几个弯，先拆成两半。

第一半：要算什么。「the height range (defined as the difference between maximum and minimum height) of all dogs that share a fur type」——按毛发类型把狗分堆，每堆算一个「身高极差」＝最高的减最矮的。

第二半：哪些堆有资格进入结果。「we'll only consider fur types where each dog with that fur type is within 30% of the average height of all dogs with that fur type」——只保留那些满足「组里每一只狗的身高都在本组平均身高上下 30% 之内」的堆。题面把它翻译成了两条更好写的条件：

• 组里没有任何身高小于平均值的 0.7 倍；
• 组里没有任何身高大于平均值的 1.3 倍。

输出两列，顺序是毛发类型、身高极差。期望输出（hw/hw06/tests/low_variance.py）：

sqlite> SELECT * FROM low_variance;
curly|1

只有一行。边界情况提醒：题面的示例表格里写的是 Curly（首字母大写），但真实数据里 fur 列存的是小写 curly，评分器要的也是小写。别被题面的排版误导去做大小写转换。

怎么想到的（一）：识别出「这是分组题」

前三题的输出都是「每行对应一个原始行（或一对原始行）」。这题不一样：输出的一行对应的是一整组狗——curly 那一行代表 finn 和 hank 两只狗压缩成的一行。

识别出来之后，骨架马上就有了：SELECT ... FROM dogs GROUP BY fur。注意这题只用一张表——毛发和身高都在 dogs 里，没有任何连接。前三题连接连惯了的人有时会下意识加个 , sizes，那是多余的。

然后是「极差」。SQL 提供了 MAX() 和 MIN() 两个聚合函数，在 GROUP BY 之下它们作用于每一组内部。所以极差就是 MAX(height) - MIN(height)。

怎么想到的（二）：条件该写在哪里

这是本题真正的难点。条件是「组里最矮的狗不低于组均值的 70%，最高的不超过 130%」。第一个念头往往是塞进 WHERE：

-- 错的
SELECT fur, MAX(height) - MIN(height) FROM dogs
  WHERE height >= 0.7 * AVG(height) AND height <= 1.3 * AVG(height)
  GROUP BY fur;

sqlite 会直接拒绝：Error: misuse of aggregate function AVG()。为什么？因为WHERE 在分组之前执行，那时候「组」还不存在，AVG 无从算起。SQL 的执行顺序是死的：

FROM      把表摆出来（若有多张则做笛卡尔积）
  ↓
WHERE     逐行判断，扔掉不合格的【行】       ← 此处还没有组，不能用聚合函数
  ↓
GROUP BY  把剩下的行按 fur 归堆
  ↓
（聚合）   每堆算出 MIN/MAX/AVG/COUNT
  ↓
HAVING    逐组判断，扔掉不合格的【组】       ← 此处组已存在，可以用聚合函数
  ↓
SELECT    挑列
  ↓
ORDER BY  排序

条件涉及 AVG(height)，而 AVG 只有在分组之后才有意义，所以条件必须写在 HAVING 里。

还有一个弯：「每一只狗都在范围内」怎么写

题目说的是「each dog with that fur type is within 30%」，这是一个「对组内所有元素成立」的全称命题。SQL 里没有 FOR ALL。怎么办？

这里需要一个小小的逻辑转换，而题面 Hint 已经替你做了一半：

这一步是本题最值钱的思维。「对所有元素成立」这类条件，只要条件是单调的（比如「≥ 某阈值」），就能等价改写成「对极值成立」。这个技巧不限于 SQL——你在写循环判断「列表里所有数都大于 k」时，用 min(lst) > k 也是同一回事。

顺便注意：MIN、MAX、AVG 在这条语句里被用了两遍（SELECT 里一次、HAVING 里一次），完全没问题——它们对同一组算出的值是一样的，数据库会自己优化。

代码

-- Height range for each fur type where all of the heights differ by no more than 30% from the average height
-- Group the dogs by fur type; HAVING then filters out whole groups whose
-- shortest or tallest dog strays more than 30% from the group's average.
CREATE TABLE low_variance AS
  SELECT fur, MAX(height) - MIN(height) FROM dogs
    GROUP BY fur
    HAVING MIN(height) >= 0.7 * AVG(height)
       AND MAX(height) <= 1.3 * AVG(height);

关于 0.7 * 而不是 * 0.7：无所谓，乘法可交换。但要注意 AVG() 返回的是浮点数（sqlite 的 AVG 总是返回 REAL），所以 0.7 * AVG(height) 是浮点乘法，不会发生整数除法截断的问题。如果你自己写成 SUM(height) / COUNT(*)，那就是整数除法，119 / 3 会得到 39 而不是 39.67——这是个真会咬人的坑，所以老老实实用 AVG。

验证：手动跑一遍

GROUP BY fur 把 8 只狗分成三组：

组 curly:  finn(32),  hank(31)
组 long:   ace(26),   charlie(47), daisy(46)
组 short:  bella(52), ellie(35),   ginger(28)

逐组算聚合值，再用 HAVING 裁决：

身高 = {32, 31}
MIN = 31    MAX = 32
AVG = (32 + 31) / 2 = 31.5

条件一：MIN >= 0.7 * AVG
        31 >= 0.7 * 31.5 = 22.05      31 >= 22.05  真 ✓
条件二：MAX <= 1.3 * AVG
        32 <= 1.3 * 31.5 = 40.95      32 <= 40.95  真 ✓
两条都真 -> 保留

输出值：MAX - MIN = 32 - 31 = 1
这一行是  curly|1

身高 = {26, 47, 46}
MIN = 26    MAX = 47
AVG = (26 + 47 + 46) / 3 = 119 / 3 = 39.666666...

条件一：MIN >= 0.7 * AVG
        0.7 * 39.6667 = 27.7667
        26 >= 27.7667  假 ✗   <- ace 太矮了，只有均值的 65.5%
两条不全为真 -> 整组丢弃

身高 = {52, 35, 28}
MIN = 28    MAX = 52
AVG = (52 + 35 + 28) / 3 = 115 / 3 = 38.333333...

条件一：MIN >= 0.7 * AVG
        0.7 * 38.3333 = 26.8333
        28 >= 26.8333  真 ✓   <- ginger 险险过关
条件二：MAX <= 1.3 * AVG
        1.3 * 38.3333 = 49.8333
        52 <= 49.8333  假 ✗   <- bella 太高了，是均值的 135.7%
条件二失败 -> 整组丢弃

三组只剩一组，最终输出：

curly|1

与 tests/low_variance.py 的期望一致。

5. 整份作业回顾

四道题的题面看着像四件不同的事，其实练的是同一套动作在不同复杂度下的组合。真正带得走的是下面这些。

心法一：所有查询都是「摊平 → 筛行 → 分组 → 筛组 → 挑列 → 排序」

这条流水线解释了本次每一道题：

下次卡住时，就照这六格逐格问自己「这一格我要填什么」，比盯着题面干想有效得多。

心法二：没有「查找」，只有「配对 + 判断」

从命令式转到声明式，最难的就是戒掉「去另一张表里查一下」的念头。SQL 的世界里，你能做的只有：把可能相关的东西全部配出来，然后写一个布尔表达式说明什么样的配对是合法的。

一旦接受这一点，很多东西就不再需要死记：

• 要用两张表的信息 → 把两张表并进 FROM；
• 要用同一张表的两行 → 把这张表并两次，起两个别名（Q3 siblings）；
• 要查两只狗各自的属性 → 把属性表并两次（Q3 sentences 的 x 和 y）。

心法三：用 < 处理「无序对」

a.child < b.child 这一招同时解决自配、去重和排序三件事。它的一般形式是：当你要枚举一个集合里的无序对时，给元素定一个全序，然后只保留「小的在前」的那一半。Python 里的 for i in range(n): for j in range(i+1, n)、SQL 里的 a.x < b.x，是同一个想法的两种写法。这在期末考的 SQL 题和组合枚举题里都会再遇到。

心法四：全称命题化成极值判断

「组里每一只狗都在范围内」在 SQL 里没有直接对应的写法，但它等价于「组里最矮和最高的都在范围内」。凡是「对所有元素都成立」且条件单调，就往极值上转。

各题对照表

调试 SQL 的实用建议

SQL 最难受的地方在于它很少报错，只是给你错的答案。几条自救办法：

---------------------------------------------------------------------
Test summary
    4 test cases passed! No cases failed.