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

Question

相当理论性的问题，但从长期发展来看很重要:

场景 A(一般情况):

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

场景 B:

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

意见？我总结的是否完全正确/错误？有人有这方面的经验吗？

Answer 1

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

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

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

为什么？主要原因是可维护性，并且在许多方面。通过将所有查询访问包装到 View 中，您可以保护应用程序免受底层数据结构的更改。毕竟，事情在变化，用户需求在增长，有时数据模型必须反射(reflect)这一点。

其次，DBA 可以在一处查看所有查询。这为数据库和查询的改进、整合、简化和优化打开了空间。

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

此外，使用 View 和存储过程可以提供相当自然的 SQL 注入(inject)保护——不完全是，但是很多。但在许多数据库中，您可以阻止用户直接修改表，同时通过存储过程为他们提供修改权限。