From 7d9367e5a48e03fa6ea21fe7640457167457e9c9 Mon Sep 17 00:00:00 2001 From: mba1398 Date: Fri, 25 Dec 2020 22:10:39 +0800 Subject: [PATCH] =?UTF-8?q?Update=20Task04=EF=BC=9A=E9=9B=86=E5=90=88?= =?UTF-8?q?=E8=BF=90=E7=AE=97.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Task04:集合运算.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Task04:集合运算.md b/Task04:集合运算.md index 95e4f2b..a6348e3 100644 --- a/Task04:集合运算.md +++ b/Task04:集合运算.md @@ -832,7 +832,7 @@ SELECT P.product_id ![图片](https://github.com/datawhalechina/team-learning-sql/blob/main/img/ch04/ch04.27.png) -观察发现, 少了在所有商店都无货的高压锅和圆珠笔. 聪明的你可能很容易想到,在WHERE子句中增加 quantity IS NULL 的条件, 然而在真实的查询环境中, 由于数据量大且数据质量并非如系统说明和我们设想的那样"干净", 我们并不能很容易地意识到缺失值等问题数据的存在, 因此,还是让我们想一下如何改写我们的查询以使得它能够适应更复杂的真实数据的情形吧. +观察发现, 少了在所有商店都无货的高压锅和圆珠笔. 聪明的你可能很容易想到,在WHERE过滤条件中增加 **`OR quantity IS NULL`** 的条件, 便可以得到预期的结果。然而在真实的查询环境中, 由于数据量大且数据质量并非设想的那样"干净", 我们并不能容易地意识到缺失值等问题数据的存在, 因此,还是让我们想一下如何改写我们的查询以使得它能够适应更复杂的真实数据的情形吧。 联系到我们已经掌握了的SQL查询的执行顺序(FROM->WHERE->SELECT),我们发现, 问题可能出在筛选条件上, 因为在进行完外连结后才会执行WHERE子句, 因此那些主表中无法被匹配到的行就被WHERE条件筛选掉了.