sql - 如何编写干净的 SQL Server 存储过程

Question

在开发存储过程时，代码通常很不干净。将存储过程代码分解为单一职责(CTE、长选择列表、分解会增加更多功能/过程和复杂性)通常是不切实际的。 PL/SQL 提供包，但在 SQL Server 中没有等价物，我对这些包的经验很少，无法衡量它们对清洁代码问题的帮助。

我的一个项目在很大程度上依赖于存储过程，其中许多项目有 500 多行代码。

在看了关于 Clean Code 的演示文稿后，我想知道是否有任何关于将这些概念应用于数据库的建议。

简而言之，鉴于需要大量代码的趋势以及当项目归属于数据库繁重模型时，有哪些方法(工具、方法)用于使数据库代码更具可读性和可维护性？

Answer 1

我个人不会担心数据库术语中的清洁代码。您需要担心的是数据完整性以及性能和安全性。

我相信随着您对数据库模型越来越熟悉，理解那些长过程会变得更容易。我做的一些事情是帮助以后进行故障排除:
如果 proc 具有动态 sql，请始终使用调试变量模式编写它，您可以使用它来获取构建的 SQL 代码。这将节省数小时的故障排除时间。

如果 proc 做了很多工作，请确保将其放入带有 Try Catch 块的事务中，以便在出现问题时回滚所有内容。您还可以利用回滚不影响表变量的事实，并在回滚后将所需的调试和错误信息存储在异常表中。这将使 prod 更容易查看失败时会发生什么。

尝试在您的间距和结构上保持一致。有多种工具可用于格式化。一致的别名也有帮助。为引用的每个字段取别名，因为 6 个月后您可能不会轻易记住它来自哪个字段。就我个人而言，如果所有内连接都在左连接之前，我发现更容易理解长过程。这让我很容易看到哪些表必须有数据，如果结果错误，通常应该归咎于其中之一，因为它应该是左连接。

在您的参数数据类型中保持一致。使它们与您将使用该参数引用的字段的数据库数据类型相匹配。

将所有内容存储在源代码控制中，并无情地删除所有注释掉的代码。如果一个参数没有被使用，去掉它。如果某些内容是硬编码的，您可能希望将其转换为参数，尤其是在它被多次使用的情况下。

如果您有一些稍后可能不容易弄清楚的业务逻辑，请在注释中对其进行解释。

尝试分部分构建新的 proc，以便您可以随时轻松测试结果。例如，假设您正在制作所有退回订单的财务报告。您可能首先编写一个 cte 或临时表或表变量来获取所有返回值。然后，您可以加入其中以获取仅这些返回的财务记录并汇总它们。最后，您会将所有这些与报告中所需的其他详细信息结合起来。因此，您可以通过仅运行第一部分并查看该期间内有 2098 次返回来进行检查。汇总财务信息后，您应该为这 2098 份返回中的每一份都有一个记录。然后在最后你可以看到你仍然拥有所有需要的记录。这有助于确保您在加入过程中不会丢失任何数据，除非数据是您应该拥有的并且您明白为什么这样做。您还可以查看是否从一对多表的连接中获得了额外的记录，这些记录可能合适也可能不合适(这就是理解数据模型至关重要的原因)。

如果您要编写复杂的 sql，您需要阅读一些关于性能调优的书籍(了解相关子查询和游标之类的构造以及使用什么来代替)以避免使用以及如何确保您的 where 子句是 sargable。有几本可用于 SQL Server 性能调优的书籍。您还需要阅读有关 SQL Antipatterns 的书，它比干净的代码书更有帮助:http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?ie=UTF8&qid=1406570810&sr=8-1&keywords=sql+antipatterns