Question

我不太习惯写很长的SP。而且我发现在使用这些宽表时很快变得难以管理。即使是简单的UPSERT也会花费很长的行或数十行代码（我发现col / line样式对我来说更容易阅读，但是使用这些非常宽的表确实让我很痛苦）。逐渐地，我发现自己开始使用BEGIN / END将那些UPSERT和其他基本操作包装在同一张表上，以将它们分组为逻辑部分。因此，可以在IDE中轻松折叠和展开它们，以进行检查和评论。注意：我没有为任何控制块编写代码。只需简单的BEGIN / END，即可将它们包装到可折叠的部分中。

是否将一些额外的BEGIN / END添加到组中并折叠/展开冗长的代码会导致任何副作用？目前我还没有看到... 如果是这样，他们会是什么？有没有更好的方法来在SP中组织这些代码？

哦，我是说折叠

CREATE PROCEDURE/MULT_STATEMENT_FUNCTION
...
BEGIN
-- UPSERT QC records
    BEGIN
        UPDATE QC_SECT1 <-- fold[]
        SET COL1=...
            COL2=
            .....
        IF @@ROWCOUNT.... <--fold[ click 1]
        INSERT INTO ... <-Fold[click 2]
        (
            COL1
            ....
        VALUES          <-Fold[click 3]
        (
            ...
    END
    -- calculate distribution
    BEGIN
    DECLARE @GRP1_.....
    DECLARE @GRP2_....
    WITH .....
    ....
    ) AS PRE_CAL1  <-- fold[click 1]
    ) AS PRE_CAL2  <-- fold[click 2]
    ) AS ...       <-- fold[click 3] 
    END
END

我发现检查长脚本非常不便，逐渐发现自己开始使用BEGIN / END。在VSCode中，要折叠一条CTE语句需要点击太多。开始/结束使它变得容易得多。但是我真的想确定我做错了。

PS：按行分组的想法非常有效，我完全同意。关于颜色/线条样式。不是我真的很喜欢它。但我想在目前的情况下，很多人可能也会喜欢它。供应商数据库中的宽表的长前缀为，对列进行分组。垂直列出它们有助于使它们对齐，从而使它们更容易区分...我想我的当前是特例。

谢谢。

Answer 1

您可以执行此操作。构造这样的代码是个好主意，因为它以不添加注释的方式与语言和IDE集成在一起。在C语言中，有时我需要使用{}块，以防有必要使用更大的方法。

我发现颜色/线条样式更易于阅读

如果这对您来说更容易，那是有道理的。但是，也许有必要训练您的眼睛接受一种样式，其中许多列成一行。这样可以节省大量的垂直空间。更适合在同一屏幕上使用，清晰度更高。

Answer 2

不，绝对不是。将代码块包装在BEGIN / END块中没有害处。我已经做了10多年了，没有任何后果。除非没有理由评估BEGIN / END逻辑（例如，针对循环或其他“ WHILE”条件），否则优化器基本上不会对其进行忽略。

在SSMS中使用BEGIN / END代码块可以快速折叠/扩展大代码块。下面是一些我正在收集一些常规元数据的代码。它是110行代码，但易于阅读。

使用BEGIN / END组织SQL代码有什么害处？

2 个答案: