MySQL 中的存储函数 - 值得吗？

Posted 2023-03-27

【中文标题】MySQL 中的存储函数 - 值得吗？

【英文标题】：Stored Functions in MySQL - Worth Doing?

【发布时间】：2011-04-26 17:37:28

【问题描述】：

当我第一次接触数据库时，我使用的是 SQL Server。我最初是用经典的 ASP 进入的。我们被告知的一件大事是，如果您使用存储过程，而不是使用 ASP SQL 命令（我想是“在线”执行它），那么您在 SQL 事务中节省了大量时间。所以几乎所有我想对数据库做的事情都写了一个存储过程，然后从我的代码中调用这个存储过程。

不管怎样，快进几年，我现在正在使用 php 和 mysql（以及一点 Python）来完成我的所有工作。我似乎根本看不到的一件事是人们使用存储过程/函数，所以我并没有真正担心它。

但是，我突然想到，我只是做错了，并没有意识到这一点。在 MySQL 中使用存储函数有主要优势吗？我正在构建一个相当大的网站来处理对数据库的大量调用。这些调用都是在我的 PHP 代码中完成的。我会更好地使用存储函数来进行我一贯进行的调用，然后只将变量从 PHP 传递给函数吗？

【参考方案1】：

这取决于。存储过程是一种处理功能分解的方法，如果您有多个应用程序与同一个数据库进行交互，它绝对是必不可少的。几年前，对所有事物都使用存储采购的想法正在兴起，随着世界转向服务/RAD 世界，他们正在失去一些优势。

存储过程的一些好处是

重用/这当然可以在您的代码库中完成，但它比编写具有 10 个子连接 15 次的相同查询要好得多

安全性 - 当 sp 盛行时，sql 注入攻击出现在最前面，减少暴露的一种方法是提供参数化 sp，在大多数情况下自动清理您的输入

关于真正大型数据库表布局的定义文档并不总是足以解释您存储的内容以及原因以及 SP 有时会为您和之后的人提供预期的内容

已定义的接口。

我认为所有这些优点都可以提供，前提是应用程序设计良好，并且只能在一定程度上在一定规模的项目中制作场景。

一些缺点

冗余功能 - 我见过很多商店，其中业务和 crud 逻辑分布在应用程序中，业务逻辑在数据库中。

缺乏对 SP 的配置管理 -- 虽然已有用于代码的既定程序和工具，但 SP 管理远远落后。

【讨论】：

"几年前" ?多年来，我已经看到它们在下降。

【参考方案2】：

这与问“我应该将代码分解为方法/函数/过程并调用它们还是应该将所有内容都编码到当前函数中？”是同一个问题？

存储过程为您带来的一些优势：

更容易测试。您可以在不运行应用的情况下测试存储过程。 更容易开发。您可以让 DB 开发人员编写存储过程，让 GUI 开发人员编写 UI，等等。 更容易移植到不同的数据库。更改都包含在数据库中，与应用程序的合同（传递给存储过程的参数）不应更改。 能够从多个前端使用存储过程中的逻辑。您不必在每个需要创建新客户的应用中编写相同的客户创建逻辑。

最大的缺点是您必须学习多个学科并且可能使用多种工具。这是在 .Net 中使用 Linq for SQL 的重要原因之一。您不必学习 SQL，所有内容都包含在 .Net 代码中。

我们对所有事情都使用存储过程。它工作得非常好。抽象是你的朋友。

【讨论】：

我认为还有另一个缺点：可扩展性。数据库可能是架构中最难扩展的部分。可以做到，但比添加更多 PHP 或 Java 服务器更具挑战性。因此，如果可扩展性是一个问题，您可能需要平衡将多少业务逻辑放入数据库服务器，以及将哪些业务逻辑分布在您的网络/应用服务器中可能更好地扩展。

版本控制呢？如果 SQL 在源代码中，则对 SQL 的更改将存储在源代码存储库（SVN、CVS 等）中。

Michael，我们所有的存储过程源代码都在 TFS 中。您说得对，如果 SQL 存储在应用程序的源中，则更易于管理。

Marvo，我们使用 Sql Server、Oracle 和 Teradata，我们的 DBA 似乎能够很好地扩展数据库。