多值存储过程参数只是不好的做法吗？答案

【问题标题】：Is a multi-valued stored procedure parameter just bad practice?多值存储过程参数只是不好的做法吗？
【发布时间】：2010-07-20 02:04:03
【问题描述】：

我对将多个 ID 参数传递给单个存储过程有一种奇怪的反感。例如，这感觉就是错误的：

GetMyObject(ListofIDs, OtherParam1, OtherParam2, ...)

我知道该怎么做（如果我必须这样做，那就正确）.. 但我觉得我不应该这样做。我觉得它违背了“获取项目”存储过程/子例程的目的。我觉得我应该构建我的 SP 来支持适当的过滤器参数。如果我的调用者有一个 ID 列表，他们不应该多次调用 sp 吗？

帮助？

【问题讨论】：

如果调用者经常需要一堆对象，并且有一堆 id，我不会强迫他们多次调用单个过程。不同意 GetItem(...) 返回多个项目，但 GetItems(...) 这样做没有问题。数据库调用很昂贵。

【解决方案1】：

“通过 ID 获取项目”例程不应返回多个对象，因为这绝对没有语言意义。

“通过 ID 获取项目”例程？当然，如果您有一个不错的用例，并且会经常使用它。

但大多数时候，是的，您需要一个根据应用程序适当的过滤参数返回项目的例程，而不是按 ID 返回多个项目的例程（例如，“给我从 1 月 8 日开始的所有交易，价格超过 10 美元” )。

顺便说一句，有时一系列 ID（例如 5 到 10 之间的所有内容）是一组完全有效的过滤器！

顺便说一句，这不一定只是 MySQL 或 SQL 的一般问题。几乎任何类型的任何语言的数据集查询 API 都会提出这些相同的设计问题，并且它们的答案通常会非常相似。

【讨论】：

我想这是一种有趣的思考方式。为什么一个 ID 范围不能是一组过滤器？我一次又一次地看到的问题是，为了“性能”，应用程序将需要一次调用中的所有项目（对于 ID 列表）。因此，他们希望使用 16 个 ID 进行一次呼叫，而不是拨打 16 个电话。
@deLux_247：如果应用程序需要这样的调用，请给他们。对于某些用例来说，这不是一个不合理的选择。但我会仔细研究为什么应用程序需要它——它从哪里获取ID？如果它们首先来自数据库，为什么不直接请求它需要的数据呢？真的会有那么多ID吗？例如，如果用例一次只有两个或三个，我不明白为什么它不能为每个 ID 调用一次，除非您的基础设施严重过载。