MySQL程序开发而不是发送大查询

Question

相当具有理论性的问题，但对于较长期的发展来说很重要：

情景A（一般情况）：

• 我在客户端建立查询，并将它们发送到服务器。 （通过PHP，Perl，无论如何）
• 优点：更快速的开发，因为查询字符串仅在客户端构建，并且可以轻松修改（代码必须在客户端修改）。 CRUD可以很容易地开发OO（面向对象）。
• 缺点：如果查询更大，更相似，我必须发送一个长查询字符串，在重复的情况下，我应该更好地准备它们以节省网络负载。 （例如，执行大量INSERT语句的导入脚本/应用程序）。

情景B：

• 我创建了一些常用的过程来为我的表获取或创建数据，这些过程具有一些常规输入参数，并由他们在服务器端构建查询字符串。
• 优点：我使用参数“低网络负载”向服务器发送一个简短的查询字符串。
• 缺点：开发需要更长时间，创建概括来概括查询，客户必须知道程序及其版本。

评论？它完全是真/假，我总结了什么？有人有经验吗？

Answer 1

恕我直言，使用存储过程的基本原理并不是查询字符串的大小：即使是非常长的查询字符串也会产生可忽略的网络开销，而不是返回数据时的获取阶段。

这还没有谈到查询的实际执行情况：我还没有看到一个受网络带宽限制的mysql服务器，而不是磁盘或CPU。

哪些存储过程为您提供了更高级别的抽象：如果您有名为CreateFoo()和GetFooById()的存储过程，您的应用程序无需知道foo是如何进行的存储在您的数据库中（包括所有关系奇数）。

这对于维护很有用，而且最重要的是它对于健壮性有好处：如果您不需要了解foo中涉及的表结构，您的应用程序就没有机会搞砸了 - 例如忘记连接表等。

在本质上，这意味着，您的数据库需要更少地信任您的应用。在许多情况下，应用程序永远不具有直接操作表的权限 - 他们可能仅调用存储过程（例如Banking）

那就是说，存储过程不是灵丹妙药。使用正确的工具，常识和良好的睡眠似乎有很大的帮助。

Answer 2

如果您正在开发一个应用程序，那么 - 在最终状态 - 我认为应用程序中的唯一查询应该类似于select <list of columns> from view where <whatever>，并且唯一的数据操作语句应该是对存储过程的调用将适当的错误消息返回给应用程序。

换句话说，您希望为应用程序开发API。 SQL提供了一个API（insert / update / delete），但我不认为原始SQL适用于大多数数据库应用程序。

在开发过程中，我更加灵活。可能需要在应用程序端放置复杂查询以快速解决某些问题。它们应该只是迁移到数据库中。

为什么呢？主要原因是可维护性，并且在许多方面。通过将所有查询访问权限包装到视图中，可以保护应用程序免受对基础数据结构的更改。毕竟，事情发生了变化，用户需求也在增长，有时数据模型必须反映这一点。

其次，DBA可以在一个地方看到所有查询。这为数据库和查询的改进，整合，简化和优化提供了空间。

将所有数据操作放入存储过程允许您实现没有触发器的业务规则。触发器可能非常棘手，尤其是当您在实现业务规则的多个表之间启动级联触发器时。这也允许应用程序端日志记录和更易理解的错误消息。

此外，使用视图和存储过程提供了相当自然的防止SQL注入的保护 - 不是完全，而是很多。但是在许多数据库中，您可以阻止用户直接修改表，同时通过存储过程为他们提供修改访问权。

Answer 3

您最初假设中的两个主要错误。

1. 事实上，每个HTTP请求都带有很多HTTP头，最多可达几千字节。因此，查询不会是太多的负担。与多个插入相同：一个小的“INSERT INTO t SET”只是文字对的开销可忽略不计的字段= value，field =您在HTTP请求中有任何一种方式。
2. 您是否考虑过任何一种情况下的安全问题？

而且，JFYI：

  

我创建了一些常用的程序来为我的表获取或创建数据，这些数据有一些常规输入参数，并由他们在服务器端构建查询字符串

这就是至少99％的php / mysql网络应用程序（坦率地说 - 网站）的工作原理。可能是他们这样做了。