MySQL存储过程还是php代码？

Question

在没有考虑具体情况的情况下，一个一般性的问题是:与编写执行相同计算和查询的MySQL脚本相比，通常更喜欢使用PHP存储过程吗？

每种方法的优点是什么？

Answer 1

使用Jeff Atwoods "Who Needs Stored Procedures, Anyways?" from 2004的点/计数器点

SQL1)存储过程是用大型铁质数据库“语言”编写的，如PL/

(甲骨文)或T-SQL (微软)。这些所谓的语言是古老的，充满了疯狂的、不连贯的设计选择，这些选择总是源于十年来向后兼容的痛苦演变。你真的不想用这些东西写很多代码。就上下文而言，JavaScript是PL/SQL或T-SQL的一个巨大进步。

Response：" SQL“中的"S”表示“结构化”，而不是“标准化”- PLSQL和TSQL都是SQL的自定义扩展，这也发挥了ANSI SQL的作用，因为几乎没有数据库不可知的SQL。通常，如果您想要一个执行良好的查询，就不能依赖于ANSI SQL。

ORM不是灵丹妙药--由于数据库的抽象性，大多数人都支持运行本机存储过程/函数，以便获得性能良好的查询。这很好，但完全违背了ORM的目的...

我永远不会明白为什么web开发，无数技术的拼凑(HTML，Javascript/AJAX，Flash……)总是将SQL隔离为家庭中的害群之马。像所有其他人一样，你必须学习它才能从中获得一些东西。一定是你在使用其他技术时获得的即时满足感……

2)存储过程通常不能在编写UI的同一集成开发环境中进行调试。每次隔离procs中的异常时，我都必须停止正在做的事情，取出Toad副本，然后加载数据库包，看看出了什么问题。频繁地在两个完全不同的IDE之间转换，使用完全不同的接口和语言，并不是很有效率。

Response：Eclipse或Visual Studio中最初有Javascript调试器吗？不，他们允许插件是为了让产品走出国门&振兴一个以前不存在的市场。大多数在Visual Studio/Eclipse之外使用Firebug都没有问题，为什么SQL调试要有所不同呢？

3)当出现错误时，存储过程不会提供太多反馈。除非proc是使用奇怪的T-SQL或PL/SQL异常处理进行内部编码的，否则我们会得到基于proc中失败的特定行返回的神秘的“错误”，例如Table没有行。呃，好吗？

Response：您不熟悉并不是一门糟糕的语言。就像你从来没有在谷歌上搜索过你选择的语言中的奇怪错误一样…至少Oracle & MySQL会给你错误的参考号。

4)存储过程不能传递对象。所以，如果你不小心，你可能会得到无数的参数。如果您必须使用proc使用20+字段来填充表行，请使用20+参数。最糟糕的是，如果我传递了一个错误的参数--太多、不够或错误的数据类型--我会得到一个通用的“错误调用”错误。Oracle不能告诉我哪些参数出错！因此，我必须手动钻研20个参数，以找出哪个是罪魁祸首。

SQL ：是基于集合的，与过程化/面向对象编程完全不同。类型与对象很接近，但在某些情况下，需要在过程化/OO对象和数据库实体之间建立映射。

5)存储过程隐藏了业务逻辑。我不知道proc在做什么，也不知道它会返回给我什么样的游标(DataSet)或值。我不能查看proc的源代码(至少，如果我有适当的访问权限，不求助于#2 )来验证它实际上正在做我认为它是什么--或者设计者想要它做什么。内联SQL可能并不美观，但至少我可以在上下文中看到它，以及其他业务逻辑。

Response：这是一件好事(Tm)--这就是你获得模型-视图-控制器的方式，这样你就可以拥有任何多种语言的前端，而不必每次都复制逻辑，同时处理每种语言的怪癖来复制逻辑。或者，如果有人直接连接到数据库，数据库允许添加坏数据，这是好事吗？在应用程序和数据库之间来回奔波会浪费时间和资源，您的应用程序将永远无法收回。

Answer 2

我认为杰夫·阿特伍德在2004年关于存储过程的讨论一针见血：

Who Needs Stored Procedures, Anyways?

在广泛使用存储过程和动态SQL之后，我肯定更喜欢后者:更容易管理、更好的封装、数据访问层没有BL、更大的灵活性等等。实际上，每个主要的开源PHP项目都在存储的proc上使用动态SQL (参见: Drupal、Wordpress、Magento等)。

这种对话几乎看起来很过时:给自己买一个good ORM，停止为数据访问而烦恼，开始构建令人惊叹的应用程序。

Answer 3

对我们来说，使用存储过程是绝对关键的。我们有一个相当大的.net应用程序。重新部署整个应用程序可能会让我们的用户在短时间内离线，这是完全不允许的。

但是，当应用程序运行时，我们有时必须对查询进行细微的修改。简单的事情，如添加或删除NOLOCK，甚至可能更改相关的连接。这几乎总是出于性能方面的原因。就在今天，我们遇到了一个由无关的NOLOCK引起的bug。2分钟即可定位问题、确定解决方案并部署新流程:零停机时间。在代码中使用查询这样做，至少会造成较小的停机，可能会激怒很多人。

另一个原因是安全性。对于proc，我们将用户id (非连续的，不可猜测的)传递给每个proc调用。我们验证用户是否有权在web应用程序中运行该函数，并再次在数据库本身中运行该函数。如果我们的web应用程序被攻破，这将极大地提高黑客的门槛。他们不仅不能运行任何他们想要的sql，而且即使要运行一个进程，他们也必须有一个特定的授权密钥。这是很难获得的。(不，这不是我们唯一的辩护理由)

我们的proc处于源代码控制之下，所以这不是问题。此外，我不必担心我如何命名事物(某些ORM讨厌某些命名方案)，我也不必担心飞行性能。要正确地调优ORM，您需要了解的不仅仅是SQL。您必须了解ORM的特定行为。