是否存在将合格内联表值函数改写为存储过程的合理理由？

当然有不少实际场景值得这么做，以下是最常见的几个理由：

• 复杂逻辑扩展空间更大：内联表值函数只能是单条SELECT语句，没法使用临时表、表变量做中间计算，也加不了IF/ELSE、WHILE这类流程控制。如果后续需求要给现有逻辑添加这类操作，存储过程直接就能修改，不用重构整个逻辑结构。
• 权限控制更安全：存储过程可以单独给用户分配执行权限，无需开放底层表的直接访问权。但内联函数本质是「参数化视图」，用户必须拥有函数涉及的所有表的SELECT权限才能调用，安全性上存在短板。
• 支持非查询类操作：如果之后需要在逻辑里加入增删改数据、调用其他存储过程甚至执行系统命令，存储过程可以直接实现，而内联函数只能返回查询结果，完全做不了这些操作。
• 能返回多个结果集：内联函数只能输出一张表，存储过程却可以通过多条SELECT语句返回多个独立的结果集——比如一次性返回订单主数据+订单明细，不用让应用程序发起两次请求。
• 性能调优手段更灵活：虽然内联函数会被优化器展开到外层查询中，但存储过程可以用OPTION(RECOMPILE)强制生成新执行计划，或者手动添加查询提示，应对参数敏感的复杂场景更顺手。另外，存储过程的执行计划可以缓存，重复调用固定参数的场景下可能有性能优势（不过内联函数也能受益于计划缓存，这点需要注意）。
• 贴合现有开发流程：有些.NET团队一直沿用存储过程做数据访问，老的ADO.NET代码对存储过程的调用更成熟，开发人员也更熟悉这种模式，为了统一团队规范，哪怕逻辑能写成函数，也会改成存储过程。

内容的提问来源于stack exchange，提问作者J. Mini