php - 我应该使用存储过程来执行复杂的 SELECT 查询吗？

Question

我正在研究一个相当复杂的 SELECT 查询。我有多个分层查询嵌套在单个 SELECT 中，这变得非常难以管理。

我遇到了一些需要在多个地方执行内联 View 的地方，因此在存储过程开始时执行一次这些 View 然后对整个过程进行一些迭代似乎是一个合理的想法需要的结果。

我想知道是否有任何理由不应该或不能执行通过我的 PHP 代码调用的 Oracle 存储过程，并将结果集作为 OUT 参数返回。我倾向于仅使用 SP 来执行更新/删除/插入，但此查询的庞大规模和复杂性似乎需要对其进行分解。

如果这没有任何技术问题，请评论这是好事还是坏事？

Answer 1

Im working on what is turning out to be a fairly complex SELECT query. I have several hierarchical queries being nested in a single SELECT and it is getting to be quite difficult to manage.

好的，但为什么要使用存储过程？为什么不创建 View 呢？

I'm running into a few places where my inline views need to be executed in more than one place, so it seems like a reasonable idea to execute those once at the beginning of a stored procedure and then do some iteration over the results as needed.

同样 - View 的优秀用例。

I'm wondering if there are any reasons why I should not, or could not, execute an Oracle Stored Procedure, called via my PHP code, and return as an OUT parameter the resultset. If there aren't any technical problems with this, any comments on whether it is good or bad practice?

好吧，我不想挑起一场宗教 war ，我也不想建议反对的论点适用于你的情况。但是这里是:

• 我倾向于避免存储过程的一个原因是可移植性——我的意思主要是数据库可移植性。众所周知，存储过程语言不可跨数据库移植，而像 Oracle 包这样的内置库在这方面使情况变得更糟。
• 存储过程从您的数据库服务器获取一些额外的处理能力。这使得扩展整个应用程序变得更加困难:如果你的数据库服务器的容量由于存储过程而耗尽，并且你需要升级硬件甚至因此购买额外的 oracle 软件许可证，我会很不高兴露营者，特别是如果我可以购买便宜的网络服务器/php 盒子来代替计算的话。

我选择存储过程的原因:

• 语言的可移植性。如果数据库可移植性不是什么大问题，但您确实希望在多个应用程序之间重用逻辑，或者必须能够使用不同语言进行编码，那么存储过程可能会节省您编写特定于语言的数据库调用代码的时间。
• 复杂的权限场景。存储过程为您提供了额外级别的权限，因为您可以使用存储过程的定义者或所有者的特权来执行该过程。有时这可以解决用户需要使用某些表但不能直接访问它们的问题。
• 节省往返行程:如果您必须处理复杂的多语句事务，将它们放在存储过程中可以节省应用程序和数据库之间的往返行程，因为执行存储过程只需要一个往返行程。有时这可以让您获得更好的表现。

我想再次强调，在所有这些情况下，我仍然建议不要将所有过程逻辑都放在存储过程中。数据库最擅长存储和检索数据，像 php/java/perl/pick your poison 这样的语言更擅长处理数据。