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

EN

与实际编程语言代码不同，它们：

• 不是可移植的(每个db都有自己的PL/SQL版本。有时，不同版本的同数据库是不兼容的--我见过！)
• 不容易测试-你需要一个实(Dev)数据库实例来测试它们，因此单元测试它们的代码作为构建的一部分几乎是不可能的。
• 不容易更新/发布-你必须删除/创建它们修改用于释放它们的生产数据库。
• 没有库支持(为什么在别人有代码的情况下编写代码？)
• 不易与其他技术集成(尝试从它们调用Web服务)
• 他们使用的语言和Fortran一样原始，因此要完成有用的编码是不优雅和费力的，因此很难表达业务逻辑，尽管这通常是他们的主要目的。
• 不要提供调试/跟踪/消息日志等功能(一些DBS可能支持此功能--尽管我还没有看到)
• 缺少一个合适的IDE来帮助语法和链接到其他现有过程(例如Eclipse对java所做的)
• 熟练编写代码的人比应用程序编码者更少见，也更昂贵。
• 它们的“高性能”是一个神话，因为它们通常在数据库服务器上执行。增加数据库服务器负载，所以使用它们通常减少您的最大事务吞吐量
• 无法有效地共享常量(通常通过创建一个表并在您的过程中查询它---效率很低)。
• 等等。

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

建议在前面指定“高性能”时要谨慎。它往往导致错误的选择，而牺牲了良好的设计，它会咬你比你想象的更快。

使用存储过程会带来危险(来自那些曾经在那里过过却再也不想回去的人)。我的建议是像躲避瘟疫一样避开它们。

与编程代码不同，它们：

• 呈现SQL注入攻击几乎不可能(除非您是 动态构建与执行 SQL在您的过程中使用)
• 请求发送的数据要少得多。IPC作为标注的一部分
• 使数据库能够更好地缓存计划和结果集(诚然，由于MySQL的内部缓存结构，这在MySQL中并不那么有效)
• 易于单独测试(即不作为JUnit测试的一部分)
• 它们是可移植的，因为它们允许您使用特定于db的特性，并将其抽象到过程名称后面(在代码中，您只能使用泛型sql类型的内容)。
• 几乎从未比从代码中调用的sql慢。