简单场景中的包与存储过程？答案

【问题标题】：Packages vs Stored Procedures in simple scenarios?简单场景中的包与存储过程？
【发布时间】：2015-05-13 11:55:20
【问题描述】：

我有一个包含多个内联查询的应用程序。我的计划是将它们变成存储过程，但经过一些研究，我发现包是要走的路，但这只是访问存储过程的额外层。我所有的查询都非常简单，只有SELECT 语句和一些更“复杂”的CASE。在将它们放入存储过程之后，将它们放入包中真的有好处吗？

【问题讨论】：

我个人更喜欢同时使用包和storedproc，这取决于你对什么感到满意，以及你是唯一一个会使用这个包的人吗？如果是这样，那么在我看来，关于Oracle，为什么不使用存储过程呢？重新编译单独的存储过程与编译一个包并让其中一个存储过程失败/不编译可能更容易，那么你必须查看所有存储过程在该包中查看哪个失败与知道哪个编译失败，如果它只是一个存储过程.. 这个完全是固执己见，取决于你
我将只为演示使用独立程序。否则，在生产环境中，我找不到任何理由使用独立程序。我根据功能方面将它们包装在包中。
@lalitKumarB 将SELECT * FROM users Where user_id = 34 放入一个包有什么好处？
@User456789 你绝不能在生产数据库中使用SELECT *。
将SELECT * FROM users Where user_id = 34 放入subprogram 有什么好处？

标签： sql oracle plsql packages

【解决方案1】：

您的问题并不新鲜。关于独立程序与软件包的争论/讨论很多。

Thomas Kyte 在他的网站上很好地回答了一个类似的问题，我想引用：

因为包

中断依赖链（安装新包体时不会出现级联失效 -- 如果你有调用过程的过程——编译一个会使你的数据库失效）

支持封装——我将被允许编写模块化、易于理解的代码——而不是然后是单一的、不可理解的程序

显着增加我的命名空间。包名称在模式中必须是唯一的，但我可以跨同名包的多个过程不会发生冲突

支持重载

在需要时支持会话变量

推广整体良好的编码技术，让您编写模块化代码的东西，可以理解，逻辑上组合在一起。

如果您是一名程序员 - 您会看到软件包相对于独立软件的扩散所带来的好处程序在心跳中。

最好的是：

始终使用包。

除了演示、测试和独立实用程序（即什么都不叫，什么也不叫）

【讨论】：

我的查询非常简单，使用您列出的一半以上的选项对我来说确实没有任何好处。
这些不是我列出的，而是大多数数据库用户同意并实施的。这些被视为最佳做法。

【解决方案2】：

如果您有可以作为 SQL 语句的一部分处理的逻辑，那么，一般来说，我不建议将它们拉出并将它们转换为函数（也就是说，让我们面对现实吧，您将把它们变成什么into)，无论它们是独立的还是在包中。

原因是当您在 sql 语句中调用用户定义的函数时，该 sql 语句必须跳出 sql 引擎，切换到 pl/sql 引擎，然后再返回……对于每一行.这很可能会减慢您的查询速度。

当然，总是有例外 - 有时如果您经常调用返回相同值的函数，则可以使用函数缓存。

ETA：您说您有多个内联查询 - 如果它们都相同（或非常相似），您可能会使用子查询工厂化（又名 with 子句又名公用表表达式 (CTE)）来具体化结果。

【讨论】：