另一个主要的设计约束是数据库系统的机械性质 – 数据库编程几乎是独特的,因为它具有机械组件.查询性能受到磁头搜索和旋转延迟(数据到达磁头前的等待时间)的机械约束的限制.

这有效地排除了许多聪明的抽象,这可能会使sql更强大或更容易使用.许多数据库管理系统使用可用于脚本编写的过程备选方案来补充sql.但是,它们与DBMS交互
执行由优化器单独处理的一系列SQL查询.与各种DBMS平台一起提供的这种类型的语言有：

> Oracle’s PL/SQL和
PL / sql是
实际上是基于Ada – 这是相当的
现代标准“老派”
有它的遗留代码库
必须保持向后兼容.
这不一定是最多的
愉快的编程环境,但
它确实有结构
设备如并行和a
相当灵活的类型系统.其中一个主要
批评Java存储过程
在Oracle上是你要支付的
Oracle的基于容量的许可证
您正在运行JVM的cpu
上.
> sql Server CLR Integration.
有点类似于Oracle的Java
存储过程,这允许CLR
从C#(或任何.net)编译的模块
语言)加载到sql Server中
实例并执行的大致相同
方式作为存储过程. sql Server
也有
Postgresql风格的API用于制作
通过CLR定制聚合函数
整合等
用于混合sql / CLR代码库的钩子.
> PostgreSQL其实是
系统后端语言
最初是一体化的
发达.该系统出口一个native C API设施
自定义聚合函数,存储
引擎,程序扩展等
功能.
The language interfaces
基于此API,包括：
PL/pgSQL(定制语言类似
到PL / sql),Python,Perl
和Tcl.这使它成为
主流通过Illustra,a
商业化版本的Postgres,
然后买了
Informix(后来是
由IBM购买).钥匙
功能被并入
Informix On-Line,即
仍然由IBM销售.

这些语言的一个主要限制是与查询的有限交互
优化器(尽管Postgresql的C API确实有此支持).参与
在查询计划中,作为一流公民要求查询优化器可以对您的行动所需的资源进行合理的查看.实际上,这种与查询优化器的交互主要用于实现存储引擎.

挖掘存储引擎的这个级别是(a)如果功能完全可用,那么有点深奥(所以大多数人都不会有这样做的技能)和(b)可能比在sql中编写查询更麻烦.查询优化器的限制意味着您可能永远不会得到从Python(甚至是C#或Java)可能获得的sql的排除级别.

有效查询的最小阻力的路径可能是
使用其他语言之一使用一些程序胶水在sql中编写查询.在某些情况下,计算确实适用于程序性的方法.

这可能会成为一个麻烦,并导致大量的样板sql代码.唯一真正的选择是手工编码的sql或代码生成系统.代码生成的一个简单的例子是由元数据生成sql的框架提供的CRUD功能.在诸如Oracle Warehouse Builder或Wherescape Red之类的ETL工具中可以看到一个更复杂的例子,它通过从模型生成大量存储过程代码来工作.

正是因为这个原因,我发现自己正在半规则地建立一种或另一种代码生成系统.任何模板系统都将为此做好准备 – 从CherryTemplate开始,里程已经相当不错,但有很多这样的项目. Code Generation in Action是一本关于这个主题的好书,作者使用了一个基于ruby的系统,名字叫做我的名字.

编辑：如果您看到一个程序代码块的“显示估计执行计划”,您会注意到每个语句都有自己的查询计划.查询优化算法只能在单个sql语句上工作,因此一个过程将具有一个林的查询计划.因为程序代码可以具有’side-effects‘,所以您无法使用查询优化中使用的type of algorithms来代码.这意味着查询优化器无法全局优化程序代码块.它只能优化单个sql语句.