我应该创建存储函数/过程还是保留查询？答案

【问题标题】：Should I create a stored function/procedure or keep the query?我应该创建存储函数/过程还是保留查询？
【发布时间】：2017-10-27 17:36:01
【问题描述】：

这可能是问这个问题的错误地方，如果是，请原谅我。

所以我有一个 400 行长的 DB2 查询，但它会进行很多单独的计算，以确定客户是否可以通过按车道和终端/交货地点的零担运输来获利。

我的问题一般来说是继续以查询形式执行此操作还是通过存储函数传递一些算法会更快？它按行项目运行 OR 报告，因此在任何给定时间段内，每位客户可能有数千行/帐单。

我想我只是想向你们这些美丽的人寻求一些建议，这些人与我有不同的观点或更多的经验。

谢谢。

--编辑-- 我正在尝试提高速度，当我为 1 个客户运行它时速度足够快，但是当我在公司范围内运行它时，一个月的数据需要大约半小时（大约 4 万张账单）。
它实际上只处理 4 个表，大部分只需要 1 列数据。在最宽处，它大约有 40 列宽，但可以压缩，我只是希望能够在将它们组合并以更清晰的格式汇总之前查看在线计算。我确实使用了 With Loop as()，然后只挖掘该临时表作为最终输出。

【问题讨论】：

我的 2 美分：如果没坏，为什么要修呢？
我认为这个问题太宽泛了。您是否正在尝试提高性能？提高可维护性？保持性能但提高可维护性什么？我也是一个不解决问题的人，但在停机时间我确实会寻找简化代码的方法来提高性能和可维护性。
问题的答案取决于您在问题中忽略的因素。有多少表，表/结果集中有多少行，访问计划是什么，访问计划是最优的，性能要求是什么等。
如果你们也想插话，我已经为你们更新了我的问题，我一直在寻找建议。谢谢。

标签： sql algorithm db2 logic

【解决方案1】：

就架构而言，分解复杂性可能会很好，您可以将其分解为更小的更易于维护的模块。在有意义的地方使用存储函数或存储过程。就SQL 而言，这也为您提供了一点可重用的代码库。使用 JOIN 之类的 INNER JOIN, LEFT OUTER JOIN, FULL OUTER JOIN 等将您的结果汇总在一起，因为这将比通过 line items 中的管道更快例如，一个 FOR 循环和 CURSOR。正确的索引也会影响性能。尽管使用这种方法可能会遇到麻烦，但嵌套存储过程会被调用数百万次。每次上下文更改或过程调用都会产生很小的开销。如果需要，将结果存储在本地临时表中并重新加入它们以获得性能提升，如果逻辑正在提取大量结果并且您有多阶段数据等。希望这些提示有所帮助。

【讨论】：

这是一种想要去的方向，为了方便和高效，所以我很高兴你用你的建议打破了这些步骤，它有助于负载谢谢。
我见过一些案例，将短查询（例如 400 行）写入存储过程，结果是糟糕的性能（由于技能差、使用 java 过程、未能正确测试等）。因此，虽然动机可以完美无缺，但最终的结果才是真正重要的。
我同意毛。我对 SQL 的问题是，与 Object Oriented 代码相比，代码可以变得多大。将代码分离成 procs 有助于整体理解不同的需求，并减少主入口点 proc 或调用 SQL 语句的代码大小。 Procs 非常适合减少冗余代码。不过，我通常希望将数据库纯粹用作 数据存储。例如，我将它们更多地视为存储库，并在中间层执行大部分业务逻辑。这样，如果我的应用程序切换数据存储技术，我就不会重新开发逻辑。