意外的CASE评估逻辑

8

我始终理解，该CASE声明基于“短路”原理，因为如果先前的步骤被评估为真，则不会进行后续步骤的评估。（此答案是SQL Server CASE语句评估所有条件还是在第一个TRUE条件下退出？是否相关，但似乎没有涵盖此情况，并且与SQL Server有关）。

在下面的示例中，我希望MAX(amount)根据开始日期和支付日期之间有多少个月的时间来计算不同的月份范围。

（这显然是一个构造好的示例，但是在我看到该问题的实际代码中，该逻辑具有有效的业务推理）。

如果开始日期和付款日期之间的间隔少于5个月，则将使用表达式1，否则将使用表达式2。

这将导致错误“ ORA-01428：参数'-1'超出范围”，因为1条记录的数据条件无效，导致ORDER BY的BETWEEN子句开头的值为负值。

查询1

SELECT ref_no,
       CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 5 THEN
-- Expression 1
          MAX(amount)
             OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
             ROWS BETWEEN MONTHS_BETWEEN(paid_date, start_date) PRECEDING
             AND CURRENT ROW)
       ELSE
-- Expression 2
           MAX(amount)
             OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
             ROWS BETWEEN 5 PRECEDING AND CURRENT ROW)
       END                
    END 
  FROM payment

因此，我进行了第二个查询，以首先消除可能发生的任何地方：

SELECT ref_no,
       CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 0 THEN 0
       ELSE
          CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 5 THEN
             MAX(amount)
                OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
                ROWS BETWEEN MONTHS_BETWEEN(paid_date, start_date) PRECEDING 
                AND CURRENT ROW)
          ELSE
             MAX(amount)
                OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
                ROWS BETWEEN 5 PRECEDING AND CURRENT ROW)
          END                
       END
  FROM payment

不幸的是，有一些意想不到的行为，这意味着表达式1将被使用，即使该语句由于负条件现在被external困住而不会执行，也将得到验证CASE。

我可以用得到解决此问题ABS上MONTHS_BETWEEN的表达式1，但我觉得这应该是不必要的。

这种行为是否符合预期？如果是这样的话，“为什么”对我来说似乎不合逻辑，更像是一个错误？

这将创建一个表并测试数据。该查询只是我检查是否已采用中的正确路径CASE。

CREATE TABLE payment
(ref_no NUMBER,
 start_date DATE,
 paid_date  DATE,
 amount  NUMBER)

INSERT INTO payment
VALUES (1001,TO_DATE('01-11-2015','DD-MM-YYYY'),TO_DATE('01-01-2016','DD-MM-YYYY'),3000)

INSERT INTO payment
VALUES (1001,TO_DATE('01-11-2015','DD-MM-YYYY'),TO_DATE('12-12-2015','DD-MM-YYYY'),5000)

INSERT INTO payment
VALUES (1001,TO_DATE('10-03-2016','DD-MM-YYYY'),TO_DATE('10-02-2016','DD-MM-YYYY'),2000)

INSERT INTO payment
VALUES (1001,TO_DATE('01-11-2015','DD-MM-YYYY'),TO_DATE('03-03-2016','DD-MM-YYYY'),6000)

INSERT INTO payment
VALUES (1001,TO_DATE('01-11-2015','DD-MM-YYYY'),TO_DATE('28-11-2015','DD-MM-YYYY'),10000)

SELECT ref_no,
       CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 0 THEN '<0'
       ELSE
          CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 5 THEN
             '<5'
         --    MAX(amount)
         --       OVER (PARTITION BY ref_no ORDER BY paid_date ASC ROWS
         --       BETWEEN MONTHS_BETWEEN(paid_date, start_date) PRECEDING
         --       AND CURRENT ROW)
          ELSE
             '>=5'
         --    MAX(amount)
         --       OVER (PARTITION BY ref_no ORDER BY paid_date ASC ROWS
         --       BETWEEN 5 PRECEDING AND CURRENT ROW)
          END                
       END
  FROM payment
oracle 
— BriteSponge
source
3
FWIW SQL Server在此领域也有其怪癖，如dba.stackexchange.com/a/12945/3690
— Martin Smith
3
在SQL Server中，将聚合放置在CASE表达式内可能会迫使表达式的某些部分在您期望之前被评估。我想知道这里是否正在发生类似的事情？
— 亚伦·贝特朗
听起来很接近这种情况。让我想知道在两种不同的RDBMS中实现相同效果的实现CASE的逻辑是什么。有趣。
— BriteSponge
1
我想知道是否允许这样做（以及是否显示相同的不良行为）：MAX(amount) OVER (PARTITION BY ref_no ORDER BY paid_date ASC ROWS BETWEEN GREATEST(0, LEAST(5, MONTHS_BETWEEN(paid_date, start_date))) PRECEDING AND CURRENT ROW)
— ypercubeᵀᴹ16
@ypercubeᵀᴹ：您建议的聚合不会给出错误。评估的“深度”可能有限。投机。
— BriteSponge

Answers:

2

因此，我很难从帖子中确定您的实际问题是什么，但是我认为是在执行时：

SELECT ref_no,
   CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 0 THEN 0
   ELSE
      CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 5 THEN
         MAX(amount)
            OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
            ROWS BETWEEN MONTHS_BETWEEN(paid_date, start_date) PRECEDING 
            AND CURRENT ROW)
      ELSE
         MAX(amount)
            OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
            ROWS BETWEEN 5 PRECEDING AND CURRENT ROW)
      END                
   END
FROM payment

您仍然会收到ORA-01428：参数'-1'超出范围？

我不认为这是一个错误。我认为这是操作的事情。Oracle需要对结果集返回的所有行进行分析。然后就可以转换输出的精髓了。

解决此问题的其他几种方法是使用where子句排除该行：

SELECT ref_no,
   CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 5 THEN
   -- Expression 1
      MAX(amount)
         OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
         ROWS BETWEEN MONTHS_BETWEEN(paid_date, start_date) PRECEDING
         AND CURRENT ROW)
   ELSE
   -- Expression 2
       MAX(amount)
         OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
         ROWS BETWEEN 5 PRECEDING AND CURRENT ROW)
   END                
END 
FROM payment
-- this excludes the row from being processed
where MONTHS_BETWEEN(paid_date, start_date) > 0

或者您可以在分析中嵌入一个案例，例如：

SELECT ref_no,
   CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 5 THEN
-- Expression 1
      MAX(amount)
         OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
               ROWS BETWEEN 
               -- This case will be evaluated when the analytic is evaluated
               CASE WHEN MONTHS_BETWEEN(paid_date, start_date) < 0 
                THEN 0 
                ELSE MONTHS_BETWEEN(paid_date, start_date) 
                END 
              PRECEDING
              AND CURRENT ROW)
   ELSE
-- Expression 2
       MAX(amount)
         OVER (PARTITION BY ref_no ORDER BY paid_date ASC 
         ROWS BETWEEN 5 PRECEDING AND CURRENT ROW)
   END                
END 
FROM payment

说明

我希望可以找到一些文档来备份操作顺序，但是还没有找到任何东西...。

的CASE解析函数进行评价后短路评价发生。有关查询的操作顺序为：

  1. 从付款
  2. 最大over（）
  3. 案件。

因此，由于max over()发生在案例之前，因此查询失败。

Oracle的分析功能将被视为行源。如果对查询执行解释计划，则应该看到“窗口排序”，它是分析的生成行，并由上一个行源（付款表）提供给它。case语句是针对行源中每一行评估的表达式。因此，至少在我看来，案件发生在分析之后。

— 尼克·S
source
我赞赏潜在的解决方法-看看别人如何做总是很有趣的。但是，我有一个简单的方法来解决此问题；ABS功能在我的情况下有效。而且，这实际上可能不是错误，但如果不是，那么Oracle确实需要声明有关“短路”逻辑的广泛约定不适用于解析函数。
— BriteSponge
该答案具有解决方法和合乎逻辑的解释。我认为事情不会再确定了，因此我将其标记为答案。谢谢
— BriteSponge
1

SQL定义了做什么而不是怎么做。虽然Oracle通常会缩短案例评估的时间，但这是一种优化，因此，如果优化器认为其他执行路径可以提供出色的性能，则可以避免这种情况。当涉及分析时，这种优化差异是可以预期的。

优化差异不限于大小写。您的错误可以通过合并来重现，通常也会短路。

select coalesce(1
   , max(1) OVER (partition by ref_no order by paid_date asc 
     rows between months_between(paid_date,start_date) preceding and current row)) 
from payment;

似乎没有任何文件明确指出优化程序可以忽略短程评估。最接近的事（虽然不够紧密），我能找到的是这个：

所有SQL语句都使用优化程序，该优化程序是Oracle数据库的一部分，它确定了访问指定数据的最有效方法。

这个问题表明即使没有分析，短路评估也会被忽略（尽管有分组）。

汤姆·凯特（Tom Kyte）提到，在回答谓词评估顺序问题时，可以忽略短路。

您应该使用Oracle打开SR。我怀疑他们会将其作为文档错误接受，并在下一版本中增强文档以包括有关优化程序的警告。

— 雷·里菲尔
source
我本来打算开一个SR，但是很遗憾，我无法在我的组织中这样做。
— BriteSponge
-1

看起来像是在开窗浏览，这使Oracle开始评估CASE中的所有表达式。看到

create table t (val int);   
insert into t select 0  from dual;  
insert into t select 1  from dual;  
insert into t select -1  from dual;  

select * from t;

select case when val = -1 then 999 else 2/(val + 1) end as res from t;  

select case when val = -1 then 999 else 2/(val + 1 + sum(val) over())  end as res from t;    

select case when val = -1 then 999 else sum(1) over(ORDER BY 1 ROWS BETWEEN val PRECEDING AND CURRENT ROW) end as res from t;    

drop table t;

前两个查询运行正常。

— 塞格
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.