对于使用Transact-SQL或PL/SQL等语言将一些业务逻辑实际提交到存储过程所需的限制和冗长,我越来越感到沮丧.我希望将一些当前的数据库转换为Oracle并利用它对Java存储过程的支持,但目前还没有该选项.
对于支持其他语言的存储过程的数据库,您会推荐哪些替代方案?
在数据库管理器中使用更聪明的查询语言存在一些架构障碍.主要的一个是查询优化器.SQL的一个设计约束是它只能使用查询优化器可以访问的构造.这意味着语言及其功能与查询执行引擎和查询计划优化器的功能紧密耦合.
另一个主要的设计约束是数据库系统的机械性质 - 数据库编程几乎是独一无二的,因为它具有机械组件.查询性能受磁盘头搜索的机械约束和旋转延迟(您希望数据到达磁头之前的等待时间)的限制.
这有效地排除了许多可能使SQL更强大或更容易使用的聪明抽象.许多数据库管理系统使用可用于编写脚本的过程替代方案来补充SQL.但是,它们通过执行由优化器单独处理的一系列SQL查询来与DBMS交互.这些类型的某些语言随各种DBMS平台一起提供:
Oracle的 PL/SQL和 嵌入式Java.PL/SQL实际上是基于Ada - 它是现代标准的"老派",并且具有遗留代码库,必须保持向后兼容.它不一定是最令人愉快的编程环境,但它确实具有并行性和相当灵活的类型系统等设施的结构.Oracle上Java存储过程的一个主要批评是,您正在为正在运行JVM的CPU上的Oracle基于容量的许可付费.
SQL Server CLR集成.与Oracle的Java存储过程有些类似,它允许将从C#(或任何.net语言)编译的CLR模块加载到SQL Server实例中,并以与存储过程大致相同的方式执行.SQL Server还具有PostgreSQL风格的API,用于通过CLR集成和混合SQL/CLR代码库的其他挂钩来创建自定义聚合函数.
PostgreSQL实际上是最初开发后端语言集成的系统.系统导出本机C API,其中包含用于自定义聚合函数,存储引擎,过程扩展和其他功能的工具.
语言接口
基于此API,包括:
PL/pgSQL(类似于PL/SQL的定制语言),Python,Perl
和Tcl.
这使得它成为主流,通过Illustra,Postgres的商业化版本,然后被Informix收购(后来被IBM收购).主要功能已纳入
Informix On-Line,仍然由IBM出售.
这些语言的一个关键限制是它们与查询优化器的有限交互(尽管PostgreSQL的C API确实支持这一点).作为一等公民参与查询计划要求查询优化器可以合理地查看您的操作将采取的资源.实际上,与查询优化器的这种类型的交互主要用于实现存储引擎.
这种挖掘存储引擎的程度是(a)有些深奥,如果功能完全可用(因此大多数人都没有这方面的技能)和(b)可能比在SQL中编写查询更麻烦.查询优化器的局限性意味着您可能永远无法从SQL(尤其是Python)甚至C#或Java中获得SQL的abstration级别.
有效查询的阻力最小的路径可能是在SQL中使用其他语言中的一些程序粘合剂编写查询.在某些情况下,计算确实适用于程序方法.
这可能会成为一个麻烦,并导致大量的样板SQL代码.唯一真正的选择是手动编码SQL或代码生成系统.代码生成的一个简单示例是框架提供的CRUD功能,其中此SQL是从元数据生成的.在ETL工具中可以看到更复杂的示例,例如Oracle Warehouse Builder或Wherescape Red,它们通过从模型生成大量的存储过程代码来实现工作.
出于这个原因,我发现自己在半定期的基础上建立了这种或那种代码生成系统.任何模板系统都可以做到这一点 - 我从CherryTemplate获得了相当不错的里程数,但周围有很多这样的项目. "代码生成在行动"是一本关于这个主题的相当好的书 - 作者使用了一个基于ruby的系统,其名称逃脱了我.
编辑:如果您查看程序代码块的"显示估计执行计划",您会注意到每个语句都有自己的查询计划.查询优化算法只能在单个SQL语句上工作,因此过程将具有查询计划的林.由于过程代码可能具有" 副作用 ",因此您无法使用查询优化中使用的算法类型来推理代码.这意味着查询优化器无法全局优化过程代码块.它只能优化单个SQL语句.