嵌入式SQL与动态SQL

我目前正在做一个数据库主题。讲师正在介绍如何让其他语言（如C、C++）与（Oracle）数据库交互

我自己（在mysql上）做了一些数据库工作，使用动态sql

由于嵌入式SQL似乎仅限于少数Oracle和其他几个，所以这更像是一种锁定尝试，还是嵌入式SQL有真正的价值

Edit:我刚刚意识到，这节课正好在PL/SQL课程之后，这一事实可能很重要

最初的问题询问了参数化SQL（现在被“动态SQL”取代以改进问题）

---

旁白：我想我买的~$30的《SQL和关系理论》一书教给我的不仅仅是这门数据库课

嵌入式SQL在编译时解析。一个优点是，您还可以在编译时捕获语法错误，这可以防止某些令人尴尬的运行时错误。这还意味着SQL注入漏洞无法在运行时改变您预期的SQL语法

现在几乎所有的SQL程序员都将SQL放入字符串中，并在运行时解析这些字符串。这是动态SQL的原始定义。这也称为调用级别接口（CLI）

由于以这种方式使用SQL非常普遍，因此“动态SQL”的新定义已成为常见用法，即人们将此术语用于SQL查询，这些查询是根据应用程序逻辑和变量有条件地建立的，而不是作为应用程序中指定整个查询的固定字符串

参数化查询是一个完全独立的区别。您可以将参数占位符放入嵌入式或动态SQL中

值得一提的是，我不知道现在有谁使用嵌入式SQL（除了维护遗留应用程序体系结构）。我甚至愿意和你的讲师争辩说，他们在教授无关的、过时的技术

• Oracle 11g仍然支持各种SQL
• IBMDB2UDB9.7支持一个名为的SQL预处理器
• Microsoft SQL Server支持MS SQL Server 2000之后的嵌入式SQL
• 据报道，Sybase还停止了嵌入式SQL（但我找不到引用的参考资料）
• PostgreSQL仍然支持一个称为嵌入式SQL的预处理器
• MySQL从未支持嵌入式SQL
• 据我所知，SQLite不支持SQL预处理器

---

这占了RDBMS市场份额的绝大多数。

我也有C.J.Date的《SQL和关系理论》一书。这是关于DBMS中立的关系概念的最好的书。e、 g.设计表，编写面向关系而非基于产品的SQL

然而，我发现这本书在维护生产系统或在模式变化不太有利的实际情况下不太实用。此外，生产数据和应用程序的行为也可能对表范式的转换产生影响，例如，表可能以3NF开始，但由于性能原因最终以1NF结束。i、 e.联接和查找表越少越好

尽管如此，这是由于基于表的DBMS概念的局限性造成的，这就是为什么最近对NoSQL密钥/对数据库有很多强调的原因

回到您的主题嵌入式SQL与参数化SQL，您是否在比较应用层源代码中编写的SQL与驻留在数据库机器上的SQL（例如Oracle中的PL/SQL）

在这种情况下，我支持嵌入式SQL，我无法说出足够的理由相信业务逻辑应该驻留在应用层而不是数据库层

我是维护一个中等规模系统的团队的一员，在这个系统中，混合使用PL/SQL和嵌入式SQL，如果说Java开发人员不一定精通PL/SQL（事实就是这样），那么无论是优化性能还是维护它，都很难做到这一点。所以，如果您将所有业务逻辑都放在一个地方（最好是应用层），您将获得一分

关于数据库锁定，我相信您不必太关心这个问题。通常，当购买数据库产品以供使用时，您很少会进行更改。这种考虑的工作量、成本和风险通常太大。除非您正在转换一种范式，即从关系数据库转换为键/值数据库

---

希望这有帮助

将逻辑移出数据库层的一个原因是为了可伸缩性。我分析了一个大容量的网站，它的数据库服务器在CPU固定的情况下运行，但I/O负载很轻——与您通常期望的db服务器相反。同时，他们的PHP应用服务器的负载也非常轻。正如您可能猜到的，他们有一个开发策略，即所有数据代码都要在存储过程中实现。随着他们将更多的代码转移到PHP应用程序上，RDBMS服务器上的负载减轻了，水平可扩展性也得到了改善。感谢Bill，这是很有见地的。绝对是+1到“SQL和关系理论”！哈哈！现在坐在UOW嵌入式SQL讲座上…