PHP 开发人员应该使用 MySQL 的存储过程吗？ [关闭]

Posted 2023-04-14

【中文标题】PHP 开发人员应该使用 MySQL 的存储过程吗？ [关闭]

【英文标题】：Should PHP developers use MySQL's stored procedures? [closed]

【发布时间】：2010-06-02 00:46:08

【问题描述】：

在过去的 10 年里，我一直在使用 SQL Server 后端编写 asp.net 应用程序。那段时间，我也写过一些 php 应用，但并不多。

我打算将我的一些 asp.net 应用程序移植到 PHP，但遇到了一些问题。在 Asp.net 世界中，人们普遍认为在访问任何数据库时，使用视图或存储过程是这样做的首选方式。

我一直在阅读一些 PHP/mysql 书籍，并且开始觉得在 MySQL 中使用存储过程是不可取的。我犹豫使用这个词，可取的，但这只是我得到的感觉。

所以，我正在寻找的建议基本上是，我是对还是错？ PHP 开发人员是否使用存储过程？或者，它是被回避的东西？

【参考方案1】：

是否使用存储过程更像是酒吧里的宗教或政治讨论。 需要做的是明确定义您的应用程序层，而不是跨越这些界限。与在数据库外进行查询相比，存储过程有几个优点和缺点。

优点 1：存储过程是模块化的。从维护的角度来看，这是一件好事。当您的应用程序中出现查询问题时，您可能会同意，对存储过程进行故障排除比对隐藏在多行 GUI 代码中的嵌入式查询进行故障排除要容易得多。

优势 2：存储过程是可调的。通过让处理数据库的过程为您的界面工作，您无需修改​​ GUI 源代码来提高查询的性能。可以对存储过程进行更改——在连接方法、不同的表等方面——对前端界面是透明的。

优势 3：存储过程从客户端抽象或分离服务器端功能。编写 GUI 应用程序来调用过程比通过 GUI 代码构建查询要容易得多。

优势 4：存储过程通常由数据库开发人员/管理员编写。担任这些角色的人员通常在编写高效查询和 SQL 语句方面更有经验。这使 GUI 应用程序开发人员能够在应用程序的功能和图形表示部分上利用他们的技能。如果您让您的员工执行他们最适合的任务，那么您最终会产生更好的整体应用程序。

考虑到所有这些，有几个缺点。

缺点一： 如果逻辑完全在存储过程中实现，则涉及大量业务逻辑和处理的应用程序可能会给服务器带来过多的负载。此类处理的示例包括数据传输、数据遍历、数据转换和密集计算操作。您应该将这种类型的处理转移到业务流程或数据访问逻辑组件，它们是比您的数据库服务器更具可扩展性的资源。

缺点2： 不要将所有业务逻辑都放入存储过程中。当您必须在 Sp 语言中修改业务逻辑时，应用程序的维护和敏捷性就成为一个问题。例如，支持多个 RDBMS 的 ISV 应用程序不需要为每个系统维护单独的存储过程。

缺点3： 编写和维护存储过程通常是并非所有开发人员都具备的专业技能。这种情况可能会给项目开发进度带来瓶颈。

我可能遗漏了一些优点和缺点，欢迎评论。

【讨论】：

感谢罗曼和大家。我真的很感谢你的帮助。看来我有一些计划要做。

【参考方案2】：

也可能是因为 MySQL 直到版本 5 才获得存储过程。如果你使用准备好的语句，你应该没问题...只是不要使用内联 SQL

【参考方案3】：

几年前，我最终为 PHP/MySQL 项目编写了大量（约 3K 行）存储过程代码。根据我的经验：

MySQL 存储过程可能不会在性能方面帮助您。 使用 MySQLi 通过准备好的语句执行 SP 可能会让人头疼。 很难抽象出常见的模式 - 我发现自己重复自己的次数比我喜欢的要多。 根据 MySQL 版本和配置，您可能需要 SUPER 权限才能创建 SP。

如果您要移植使用存储过程的代码，保留它们可能是最简单的方法。将它们与 PHP 和 MySQL 一起使用当然是可能的，而且我个人不会准确地称它为不建议。如果我从头开始一个新的 PHP 项目，我可能不会选择再次使用它们。

【参考方案4】：

总的来说，我非常不喜欢存储过程，因为：

很容易在不应该存在的业务逻辑中滑倒。 需要更新存储过程的应用程序更新很难同步，尤其是在您必须恢复到以前的构建时。

对于任何数据库操作，我建议使用像 http://www.doctrine-project.org 这样的 PHP ORM 框架或像 CakePHP 这样包含 ORM 的框架。您将获得额外的好处，即能够更轻松地在 SQL Server 和 MySQL 之间切换。

【参考方案5】：

存储过程 - 通常 - 完全是浪费精力。

如有疑问，请实际衡量性能。您经常会发现存储过程增加了复杂性而没有明显的好处。您的 SP 可能没有提高性能。

有些人认为他们非常“重要”。实际衡量绩效而不是吹毛求疵或辩论至关重要。

【参考方案6】：

许多（大多数？）网络应用程序使用数据库抽象层来处理注入漏洞等。

如果您想要一个用于自己的应用程序，请查看 PDO。这是一个关于如何使用它的大教程： http://www.devshed.com/c/a/PHP/Using-PDO-Objects-in-PHP-5/

【讨论】：

带有 pdo 的完全真实的存储过程很棒。

【参考方案7】：

SQL 注入呢？ 过程允许您在 WHERE 子句上进行参数调用，减少注入危险

【参考方案8】：

这是一篇关于 MySQL 中存储过程的平衡且内容丰富的文章：http://www.linuxjournal.com/article/9652?page=0,0

在任何数据库和大型应用程序中将它们视为“浪费时间”或“难以维护”或“没有提供真正的好处”是非常不明智的。