案例陈述与编码的if陈述

蹬哥

更有效的方法是-
在sql中使用case语句处理，或在代码中使用if语句处理相同的数据。我问是因为我的同事有一个很大的查询，其中包含许多案例陈述。我建议她通过编写case语句来减轻数据库的压力。我发现它更有效…但是为什么呢？
1 Q$ L, q5 Z1 i  Q4 P. E- x& G               
解决方案:
' m: \# E8 ]+ A' j( ?8 T  a               
; e4 `) U: G. K2 _1 Q% {, U
& x  v! p) Q7 f9 H
                这里没有一个更基本的问题：这些CASE语句实际上在做什么？
& R. F4 X, f# k# k. S( C一分钟忘了表演。如果CASE仅用于转换查询的最终输出，并且实际上可以用if或select
case在ASP中替换相同的功能，则可能意味着数据库查询/过程正在尝试执行UI应负责的事情例如格式。关注点分离问题比任何可能的性能问题都更为严重。
0 ^5 \2 I# W  x) \& @+ G如果您有这样的查询：
6 i! z2 n- b, t5 O. ?SELECT InvoiceID, InvoiceDate,
: Q3 U% J& h0 P+ R% `. b7 ?    CASE WHEN PaidStatus = 0 THEN 'Unpaid' ELSE 'Paid' END
FROM ...
这真是愚蠢的，因为UI或进行数据到域映射的任何层都应该知道如何将数据库中的状态转换为其相应的描述。在查询本身中包含此逻辑没有任何意义。
8 |: W9 i5 u* r$ p$ `+ `! k! }1 v另一方面，如果CASE构造是查询的必要组成部分，例如：
SELECT
    SUM(CASE WHEN PaidStatus = 0 THEN Amount ELSE 0 END) AS TotalUnpaid,
    SUM(CASE WHEN PaidStatus = 1 THEN Amount ELSE 0 END) AS TotalPaid
FROM ...
% h! U* [, ]3 R' }6 b7 j甚至不要尝试将这种逻辑移至UI，因为数据库 要 好得多。并且在CASE语义上是查询的一部分（“计算 x的已
0 H& |* g% V2 d% _付款和未付款总额”），它不会接管任何UI函数。
5 s9 w4 ^) T4 n- f$ g2 r首先，要根据逻辑要完成的工作来担心逻辑实际上在哪里。仅当您实际上注意到严重的性能 问题时， 才应该对性能问题进行讨论。