存储过程是否提高了性能？

Question

我是网络开发的新手。

我有一个ASP.NET代码所在的应用程序服务器。我的应用程序服务器与位于不同服务器上的MySQL实例进行通信。 我想知道，通过使用带有视图的存储过程将计算从应用程序服务器移动到数据库服务器是否是一个好习惯，或者我应该继续将所有逻辑保留在应用程序服务器中并仅查询数据库以检索数据直接从表中没有存储过程和视图。

Answer 1

我强烈支持将数据库逻辑放入数据库，而不是在应用程序和服务器之间拆分。这意味着我更喜欢在存储过程和视图中包装所有数据库调用。

驱动原因是维护，安全性和功能，而不是性能，尽管服务器端的性能通常更好。

首要原因是将应用程序与基础数据结构中的更改隔离开来。因此，如果数据结构发生变化，应用程序就不会（总是）中断。

浮现在脑海中的其他原因：

• 同样的逻辑被用于同一件事。也就是说，一段代码没有以另一种方式定义“foobar”和另一种“foobar”。
• 审计和日志记录在存储过程中实现，而不是使用触发器。
• 数据库表对所有用户都是禁止的，除非它们通过定义的接口。
• 较新版本和旧版本通常可以共存。

不可否认，对于一次性，快速和肮脏的应用程序，这些问题可能并不重要。但是，我认为在系统的不同组件之间建立良好定义的接口（API）是个好主意，数据库和应用程序层是这些API非常有用的主要示例。

Answer 2

我同意Gordon在应用程序和实际数据库之间分离出一层“代码”。我对Stored Routines的实用程度提出了异议。

• PHP（等）比SProcs更具表现力。
• 一个SProc可以更快地执行多个查询，因为它更靠近服务器。如果客户端和服务器位于该国的对面，这可能会带来巨大的性能提升。
• 错误检查在SProcs中很笨拙。
• PHP仅在代码更改时重新编译; SProcs每次连接重新编译一次; Perl总是重新编译;等
• VIEWs有时候很难优化，所以我避免使用它们。

“层”的良好设计的秘诀在于拉扯任何一方的力量之间的妥协。一个例子：你能完全隐藏应用程序的架构变化吗？即使你把一张桌子分成两张？

一个非常糟糕的例子是UI使用页码进行分页。该层考虑了OFFSET和LIMIT，并将其提供给MySQL后端。接下来一个项目将是216K页（是的，那么多！）他们发现OFFSET + LIMIT不是实现“下一页”的好方法，但修复它需要对系统的所有层进行更改。