在过去的 10 年里，我一直在编写带有 SQL Server 后端的 asp.net 应用程序。那段时间，我也写过一些PHP应用，但是不多。
我打算将我的一些 asp.net 应用程序移植到 PHP，但遇到了一些问题。在 Asp.net 世界中，人们普遍认为在访问任何数据库时，使用 View 或存储过程是首选的方式。
我一直在阅读一些 PHP/MySQL 书籍，我开始觉得在 MySQL 中使用存储过程是不可取的。我对使用“明智”这个词犹豫不决，但这就是我的感觉。
所以，我正在寻找的建议基本上是，我是对还是错？ PHP 开发人员是否使用存储过程？或者，它是被回避的东西吗？
最佳答案
是否使用存储过程更像是酒吧里的宗教或政治讨论。
需要做的是明确定义您的应用程序层，而不是跨越这些界限。与在数据库外进行查询相比，存储过程有几个优点和缺点。
优点 1:存储过程是模块化的。从维护的角度来看，这是一件好事。当您的应用程序中出现查询问题时，您可能会同意对存储过程进行故障排除比在多行 GUI 代码中隐藏的嵌入式查询要容易得多。
优势 2:存储过程是可调的。通过让处理数据库的过程为您的界面工作，您无需修改 GUI 源代码来提高查询的性能。可以对存储过程进行更改——在连接方法、不同的表等方面——对前端界面是透明的。
优势 3:存储过程从客户端抽象或分离服务器端功能。编写 GUI 应用程序来调用过程比通过 GUI 代码构建查询要容易得多。
优势 4:存储过程通常由数据库开发人员/管理员编写。担任这些角色的人员通常在编写高效查询和 SQL 语句方面更有经验。这使 GUI 应用程序开发人员能够在应用程序的功能和图形表示部分上利用他们的技能。如果您让您的员工执行他们最适合的任务，那么您最终会产生更好的整体应用程序。
考虑到所有这些，有几个缺点。
缺点一: 如果逻辑完全在存储过程中实现，则涉及大量业务逻辑和处理的应用程序可能会给服务器带来过多的负载。此类处理的示例包括数据传输、数据遍历、数据转换和密集计算操作。您应该将这种类型的处理转移到业务流程或数据访问逻辑组件，它们是比您的数据库服务器更具可扩展性的资源。
缺点2: 不要将所有业务逻辑都放入存储过程中。当您必须在 Sp 语言中修改业务逻辑时，应用程序的维护和敏捷性就成为一个问题。例如，支持多个 RDBMS 的 ISV 应用程序不需要为每个系统维护单独的存储过程。
缺点3: 编写和维护存储过程通常是并非所有开发人员都具备的专业技能。这种情况可能会给项目开发进度带来瓶颈。
我可能遗漏了一些优点和缺点，欢迎评论。
关于php - PHP 开发者应该使用 MySQL 的存储过程吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2954318/