存储过程/查询在所有用例的2％中需要附加字段最佳实践？

问题描述

我在一个大型应用程序的50个不同地方都有一个存储过程。这50个上下文之一将需要此过程中的附加字段。

我可以想到两种不同的方法：

1. 更新存储过程以返回缺少的字段。 这意味着我将始终请求一些其他数据，这些数据在50个其他用例中的49个中将是无用的。
2. 让存储过程保持原样（没有所需的其他数据）。 当我需要其他数据（50个用例中的1个）时，请在SP返回之后查询基础，以将SP结果集增强为专用DTO。 在这种情况下，我会将这些额外的代码添加到我的业务层中。 这意味着需要额外的代码，并通过两个查询而不是一个查询来获取所有数据。

最佳做法是什么？

解决方法

我认为“最佳实践”并不是一个非常有用的词组-它取决于您要优化的内容。

如果您的应用程序代码可以处理其他字段，则有很多参数可以将该字段添加到结果集中。这是最少的工作，也最少的复杂性。毫不奇怪-存储过程通常返回结果集，然后由应用程序代码决定如何对该结果集进行处理（包括忽略某些列），这很常见。作为一般的“最佳实践”原则，只有一个存储过程才能返回完整的结果集，而让客户端代码决定如何处理该结果集，则使proc易于使用和重复使用，并且只要您不要更改结果集，可以更改过程的执行。在大多数情况下，传输少量额外字节的开销可以忽略不计-如果 是个问题，那么您的问题就更大了！

编辑以回复@vvgiri的评论：

如果必须连接到其他表以获取其他数据，则可能会对性能产生影响。实际上，只要联接是简单的“外键/主键”联接，除非您具有巨大数据集，否则它可能不会产生可衡量的影响，但是值得测试。

该方法的问题是您可能需要测试使用存储的proc的所有50个位置。您不会在问题中写这个；如果没有问题，我只需添加额外的字段即可。

如果它是一个问题，我会考虑可维护性和“最不惊奇”的因素。没有细节，很难说如果客户端代码调用一个存储过程然后使用其结果来获取更多数据，我是否会感到惊讶。但是，如果那会令人惊讶，我会考虑编写一个新的过程，其名称应清楚说明其存在的原因。该过程可能应该调用原始proc，然后进行扩展，返回客户代码所需的结果集。

这种方法意味着您的客户代码保持“干净”，没有任何意外或特殊情况。它重复使用原始proc-无重复。它可能比修改原始proc慢，但不比您的“选项2”慢。

,

我个人认为，我只是在过程中包括一个变量，如果需要额外的列，可以在执行查询中设置该变量，并根据需要使用此变量来调整输出