MySQL存储过程使用它们或不使用它们

Question

我们正处于一个新项目的开始阶段,我们真的想知道是否应该在MySQL中使用存储过程.

我们仅使用存储过程来插入和更新业务模型实体.有几个表代表模型实体,我们将在那些存储过程insert/update中抽象它.

另一方面,我们可以从Model层调用insert和update,但不能在MySQL中调用,而是在PHP中调用.

根据您的经验,哪个是最佳选择？两种方法的优点和缺点.哪个是高性能最快的？

PS:这是一个大多数阅读和高性能的网络项目是最重要的必要条件.

Answer 1

与实际的编程语言代码不同,它们:

• 不可移植(每个数据库都有自己的PL/SQL版本.有时同一数据库的不同版本是不兼容的 - 我已经看过了!)
• 不容易测试 - 你需要一个真实的(dev)数据库实例来测试它们,因此单元测试它们的代码作为构建的一部分实际上是不可能的
• 不容易更新/可释放 - 您必须删除/创建它们,即修改生产数据库以释放它们
• 没有库支持(为什么在其他人拥有时编写代码)
• 不容易与其他技术集成(尝试从他们调用Web服务)
• 他们使用与Fortran一样原始的语言,因此无法完成有用的编码,因此很难表达业务逻辑,即使这通常是他们的主要目的是
• 不提供调试/跟踪/消息记录等(一些dbs可能会支持这个 - 我还没有看到它)
• 缺乏一个体面的IDE来帮助语法和链接到其他现有的程序(例如Eclipse为java做的)
• 熟练编写它们的人比应用程序编码器更稀有,更昂贵
• 他们的"高性能"是一个神话,因为他们在数据库服务器上执行它们通常会增加数据库服务器负载,因此使用它们通常会降低最大事务吞吐量
• 无法有效地共享常量(通常通过创建表并从您的过程中查询它来解决 - 非常低效)
• 等等

如果您有一个特定于数据库的操作(例如,用于维护数据库完整性的事务内操作),或者保持您的过程非常原子和简单,那么您可能会考虑它们.

在预先指定"高性能"时,建议小心.它往往会导致糟糕的选择而牺牲良好的设计,它会比你想象的更快地咬你.

使用存储过程是您自己的危险(来自那里的人,从不想回去).我的建议是像瘟疫一样避免它们.

Answer 2

与编程代码不同,它们:

• 几乎不可能呈现SQL注入攻击(除非您正在 从过程中
  构造和执行动态
  SQL)
• 作为标注的一部分,要求通过IPC发送的数据要少得多
• 使数据库能够更好地缓存计划和结果集(由于其内部缓存结构,这对MySQL来说无疑是不那么有效)
• 可以单独测试(即不作为JUnit测试的一部分)
• 它们是可移植的,它们允许你使用特定于db的特性,抽象在一个过程名称后面(在代码中你被一般的SQL类型的东西所困)
• 几乎从不比从代码调用的SQL慢

但是,正如波西米亚人所说的,还有很多缺点(这只是提供另一种观点).在决定什么对你最有利之前,你可能需要进行基准测试.

Answer 3

As for performances, they have the potential to be really performant in a future MySQL version (under SQL Server or Oracle, they are a real treat!). Yet, for all the rest... They totally blow up competition. I'll summarize:

• Security: You can give your app the EXECUTE right only, everything is fine. Your SP will insert update select ..., with no possible leak of any sort. It means global control over your model, and an enforced data security.

• Security 2: I know it's rare, but sometimes php code leaks out from the server (i.e. becomes visible to public). If it includes your queries, possible attackers know your model. This is pretty odd but I wanted to signal it anyway

• Task force: yes, creating efficient SQL SPs requires some specific resources, sometimes more expensive. But if you think you don't need these resources just because you're integrating your queries in your client... you're going to have serious problems. I'd mention the analogy of web development: it's good to separate the view from the rest because your designer can work on their own technology while the programmers can focus on programming the business layer.

• Encapsulating business layer: using stored procedures totally isolates the business where it belongs: the damn database.

• Quickly testable: one command line under your shell and your code is tested.

• Independence from the client technology: if tomorrow you'd like to switch from php to something else, no problem. Ok, just storing these SQL in a separate file would do the trick too, that's right. Also, good point in the comments about if you decide to switch sql engines, you'd have a lot of work to do. You have to have a good reason to do that anyway, because for big projects and big companies, that rarely happens (due to the cost and HR management mostly)

• Enforcing agile 3+-tier developments: if your database is not on the same server than your client code, you may have different servers but only one for the database. In that case, you don't have to upgrade any of your php servers when you need to change the SQL related code.

好吧,我认为这是我在这个问题上最重要的事情.我开发了两种精神(SP与客户端),我真的非常喜欢SP风格.我只是希望Mysql有一个真正的IDE为他们,因为现在它是有限的痛苦.

Answer 4

存储过程很好用,因为它们可以使您的查询井井有条,并允许您一次执行批处理.存储过程通常可以快速执行,因为它们是预编译的,与每次运行时编译的查询不同.这对数据库位于远程服务器上的情况有很大影响; 如果查询在PHP脚本中,则应用程序和数据库服务器之间存在多个通信 - 查询将被发送,执行并返回结果.但是,如果使用存储过程,则只需要发送一个小的CALL语句而不是大而复杂的查询.

可能需要一段时间才能适应编程存储过程,因为它们有自己的语言和语法.但是一旦你习惯了它,你会发现你的代码非常干净.

在性能方面,如果您使用存储过程,它可能不会有任何重大收益.

Answer 5

我会让我知道我的意见,尽管我的强硬可能与这个问题没有直接关系:

与许多问题一样,关于使用存储过程或应用程序层驱动的解决方案的回复依赖于将推动整体工作的问题:

• 你想得到什么.

您是在尝试批量操作还是在线操作？他们是完全交易的吗？这些行动有多复发？等待数据库的工作量有多重？

• 你有什么才能得到它.

你有什么样的数据库技术？什么样的基础设施？您的团队是否接受过数据库技术的全面培训？您的团队是否能够更好地构建数据库诊断解决方案？

• 得到它的时间.

没有秘密.

• 建筑.

您的解决方案是否需要分发到多个位置？是您使用远程通信所需的解决方案吗？您的解决方案是在多个数据库服务器上工作,还是可能使用基于群集的架构？

• Mainteinance.

需要多少申请才能更改？你有经过专门训练的个人维护解决方案吗？

• 更换管理层.

您是否看到您的数据库技术将在短期,中期,长时间内发生变化？您是否经常需要迁移解决方案？

• 成本

使用一种或另一种策略实施该解决方案需要多少费用？

这些点的总体将推动答案.因此,在决定是否使用任何策略时,您必须关注每一点.有些情况下,存储过程的使用优于应用程序层管理的查询,而其他情况下,执行查询和使用基于应用程序层的解决方案时最好.

在以下情况下,使用存储过程往往更加充分:

1. 您的数据库技术不会在短时间内发生变化.
2. 您的数据库技术可以处理并行操作,表分区或任何其他策略,以将工作负载划分为多个处理器,内存和资源(集群,网格).
3. 您的数据库技术与存储的过程定义语言完全集成,即支持在数据库引擎内部.
4. 您有一个开发团队,他们不怕使用过程语言(第三代语言)来获得结果.
5. 您希望实现的操作是在数据库内置或支持的(导出到XML数据,与触发器,预定操作等相关地管理数据完整性和一致性).
6. 可移植性不是一个重要问题,您不会在很短的时间内将技术变为您的组织,甚至是不可取的.通常,可移植性被应用程序驱动和面向分层的开发人员视为里程碑.从我的角度来看,当不需要为多个平台部署应用程序时,可移植性不是问题,当没有理由进行技术更改,或者迁移所有组织数据的工作量高于改变的好处.您可以通过使用应用程序层驱动的方法(可移植性)赢得什么,您可以从数据库中获得性能和价值(为什么花费数千美元来获得法拉利,您将以不超过60 mil/hr的速度驾驶) ？).
7. 性能是一个问题.第一:在某些情况下,使用单个存储过程调用可以获得比来自其他应用程序的多个数据请求更好的结果.此外,您需要执行的某些特性可能内置在您的数据库中,并且在工作负载方面的使用成本更低.当您使用应用程序层驱动的解决方案时,您必须考虑与进行数据库连接,调用数据库,网络流量,数据包装相关的成本(即,使用Java或.NET时,存在隐式成本时使用JDBC/ADO.NET调用时必须将数据包装到表示数据库数据的对象中,因此实例化在数据来自外部时会在处理,内存和网络方面产生相关成本.

在以下情况下,使用应用层驱动的解决方案往往更加充分:

1. 便携性是一个重要问题.
2. 应用程序将部署到只有一个或几个数据库存储库的多个位置.
3. 您的应用程序将使用繁重的面向业务的规则,这些规则需要与底层数据库技术无关.
4. 您需要根据市场趋势和预算来改变技术提供商.
5. 您的数据库未与调用数据库的存储过程语言完全集成.
6. 您的数据库功能有限,您的要求超出了数据库技术的要求.
7. 您的应用程序可以支持外部调用固有的惩罚,更基于事务的业务特定规则,并且必须将数据库模型抽象为用户的业务模型.
8. 并行化数据库操作并不重要,而且,您的数据库没有并行化功能.
9. 您拥有一个开发团队,该团队没有经过良好的数据库技术培训,并且通过使用基于应用程序驱动的技术可以提高工作效率.

希望这可能有助于任何人问自己什么是更好用.