一个AI助手会在10秒内给你写出一个查询,查询会运行,回来的号码看起来完全合理.
这页给你五张支票 告诉你那号码是否正确 他们需要大约两分钟, 他们不需要任何工具 超越你已有的数据库, 他们抓住了四个错误 AI写的SQL 实际上制造。
令相关.
检查是先安排最便宜的,所以第一个需要一行一行的计数,最后一个需要简短的交谈.
大多数错误的询问都落在前两个.
简本.
运行的查询只通过语法检查 。
当行,过滤器和分母符合你所问的问题时,数字是正确的.
数据库只能查询到第一个出入口。
为什么在列表之前运行的查询仍然会出错:当数据库接受查询时,您认为数据库会实际检查什么?
语法.
这就是全部清单。
拼写表格名称错误,则出现错误。
将错误的列进行总和,加入的方式是双行相接,或者在问题之前需要时进行分组后过滤,然后在其中得到一个带错误数字的干净结果。
此页面的每一个错误都是有效的 SQL.
AI助理增加了一个具体困难:他们的查询很流利.
化名是干净的,格式化是干净的,外形看起来像一个小心的人写的.
流利读作正确,其实不是一回事.
请检查access-date=中的日期值 (帮助) 下方的示例列表运行在一个小商店数据集上,因此每个数字都可以通过手来检查. 7月有13个订单,5个顾客,还有一张表格,其中两个订单分两部分被退还. 13个订单中有11个已完成;1个被退还,1个待决。
还有一个列表列出内部账户的表格,它包含一行NULL,因为真实的取景表通常是这样做的.
完成的11个订单的总价值为1 605个。
退款共计275.
抓紧那两个数字 请检查access-date=中的日期值 (帮助) 请检查access-date=中的日期值 (帮助) 请检查access-date=中的日期值 (帮助) 请检查access-date=中的日期值 (帮助) =====中的日期值 (帮助) ================ (帮助) ========== -================= -====================================================================================================================================== 在接到退款命令的LEFT JOIN之后,查询会看到11行还是更多?
以下是一位助手为“完成订单的净收入”而写的查询: 它运行。
它返回1,830个。
正确的答案是1,330,你已经知道,因为1,605减275是1,330。
加入是问题所在。
每分两部分退了两道订单,所以每道订单与两道退道相匹配.
参赛者将11行变为13行,将这两道订单计算出两次:2,105次而不是1,605.
追加的500是两个双重计算订单的正值.
这叫做扇出:每当另一边的密钥出现不止一次时,一个会合会相乘行.
检查费用有两点: 这个比较决定了它。
如果第二个数字增加,加盟扇出 和每一个SUM或AVG 在左表的列被怀疑。
如果它保持了, 加入是安全的,你继续前进。
检查 2: 在每个过滤器中查找 NULL 接下来的要求是"相同的收入,不包括工作人员账户".
助理写道: 这返回 NULL, 从零行.
人数不多了 没什么 大声说,为什么一个NULL可以 空出整个结果, 在读之前。
这是机制。
要求,对于每个订单,"这个客户是否与列表中的每一个值不同?".
列表中的其中一个值是NULL,而SQL不能说与NULL有什么不同.
比较结果回溯未知,未知不实,无一行能活.
一个NULL一行在望台静静地空出结果.
修补方式要么将NULL排除在列表之外,要么使用没有这种行为的: 审查者习惯:对于每个列一个过滤器触碰,询问当列是NULL时,该过滤器会发生什么.
同样的失明会汇入SQL中的NULL。
检查 3: 询问过滤器坐在哪里, W