动态sql vs存储过程 - 优点和缺点？

Question

我已经阅读了许多强烈的观点（赞成和反对）SP或DS。

我正在用C ++编写一个查询引擎（mySQL后端现在，虽然我可能决定使用C ++ ORM）。我无法决定是编写SP，还是动态创建SQL并将查询发送到数据库引擎。＃

有关如何决定的任何提示？

Answer 1

这是一个简单的答案：

如果您的程序员同时执行数据库和编码工作，请将SQL与应用程序保持一致。保持这种方式更容易。否则，让DB人员在SP中处理它。

Answer 2

您可以更好地控制数据库之外的机制。在数据库之外处理这个问题的最大胜利就是维护（在我看来）。对SP进行版本控制与在数据库外部生成的代码相比有点难度。还有一件事要跟踪。

虽然我们讨论的是主题，但它与处理数据/架构迁移类似。版本/处理模式迁移非常复杂，如果您还没有这种机制，那么您将需要管理另一件事。它归结为简单地在数据库之外管理/版本化这些东西。

考虑您的SP中存在错误的情况。现在它需要更改，但随后您跳转到另一个开发人员数据库/沙箱。什么版本的沙箱和SP？现在你必须跟踪多个版本。

Answer 3

主要区别之一是您是在撰写“一个真正的前端”还是数据库是您应用程序的核心部分。

如果您将要有多个前端存储过程，那么很有意义，因为您可以减少维护开销。如果您只编写一个接口，那么存储过程很麻烦，因为在前端需要更改时，您在更改数据集时会失去很大的灵活性，而且您现在必须在两个地方执行代码维护，版本控制等操作。 。数据库与代码存储库保持同步真的很痛苦。

最后，如果您要编写多个数据库（例如，Oracle和SQL兼容代码），我将完全避免存储过程。

在某些罕见的情况下，您可能会在分析后确定某些有限的存储过程对您有用。这种情况比人们想象的要少。

Answer 4

必须拥有SP的主要方案是：

1）当你有非常复杂的查询集，编译开销很大，数据漂移足够低时，不需要定期重新编译。

2）当用于访问特定数据集的“Only True”逻辑非常复杂时，需要从不同平台上的几个不同代码库访问（因此在代码中编写多个API要贵得多）。

任何其他情况，都有争议，可以通过某种方式决定。

我还必须说其他海报关于版本控制的论点在我的经验中并不是那么重要 - 让版本控制中的SP像创建“sql / db_name”目录结构一样简单，并且具有简单的基本功能数据库发布“将SP代码从版本控制位置释放到数据库的脚本。我工作的每家公司都有这样的设置，一个由DBA运行，另一个由开发人员运行。

Answer 5

您要避免的一件事是让您的业务逻辑分布在应用程序的多个层中。数据库DDL和DML很难与应用程序代码库保持同步。

我的建议是创建一个良好的关系模式，但所有的约束和触发器，以便即使有人进入数据库并尝试通过某些命令行SQL执行某些操作，数据仍保持完整性。

将所有业务逻辑放在调用（静态/动态）SQL的应用程序或服务中，然后包装您尝试公开的业务功能。

存储过程有两个我能想到的目的。

1. 帮助简化数据访问。 存储过程没有 它中的任何业务逻辑，它只是 知道的结构 数据并公开接口 隔离访问三个表和一个 只是为了得到一块 信息。
2. 将域模型映射到数据 模型，存储过程可以提供帮助 使数据模型看起来像一个 给定域模型。

程序完成并且已经过分析后，1.0版本中经常存在性能问题。存储过程确实提供了SQL的批处理，而无需在DBMS和应用程序之间来回传输流量。在罕见和极端情况下，由于性能的原因，可能需要将一些业务规则迁移到存储过程方面。确保在多个显着位置记录架构理念的任何例外情况。

Answer 6

存储过程非常适合：

• 在复杂查询上创建可重用的抽象;
• 对表执行特定类型的插入/更新（如果您还拒绝对表的权限）;
• 执行通常不允许登录用户执行的特权操作;
• 保证一致的执行计划;
• 扩展ORM的功能（批量更新，层次结构查询等）

动态SQL非常适合：

• 变量搜索参数或输出列：
  • 可选搜索条件
  • 数据透视表
  • IN子句具有用户指定的值
• ORM实现（大多数可以使用SP，但无法在其上构建完全）;
• DDL和管理脚本。

他们真的解决了不同的问题。使用更适合手头任务的任何一个，并且不要仅限于其中一个。在您处理数据库代码一段时间之后，您将开始对这些事情有一种更直观的感觉;你会发现自己正在敲打一些老鼠的字符串，以便查询并思考，“这应该真的存放在存储过程中。”

最后注意事项：因为这个问题暗示了SQL的某种程度的缺乏经验，所以我不得不说，不要忘记在编写动态SQL 时仍需要参数化查询。参数不仅适用于存储过程。

Answer 7

DS更灵活。 SP方法使您的系统更易于管理。