共计 1494 个字符，预计需要花费 4 分钟才能阅读完成。
本文内容来自 SAP 社区博客：Calculation Engine (CE) Functions – Rest in Peace
CE Function，即 Calculation Engine，是 HANA SPS02 中引入的一种机制，它容许间接拜访 HANA 列存储。它们容许极其准确地管制如何精准投影、计算和聚合列。
事实上，它们是原始 HANA 列存储如何建模向量函数的间接示意。
CE Function 执行的效率如何？
它们齐全绕过了 SQL 优化器，意味着您想要执行的任何操作都在列存储中运行，并且您始终能够取得 HANA 的全副性能。CE 函数总是在列引擎中运行，并且如果您返回适度的后果集，则能取得很高的执行效率。它们实际上无效地编译成一种称为 L 的语言，它是 HANA 的两头语言，与 C++ 十分类似。
不过 CE Function 的编写也比传统的 SQL 要麻烦一些。
您必须指定每一列，当存储过程的取数逻辑越来越简单时，这往往意味着大量的复制和粘贴以及代码的激活。编辑器不会给你太多帮忙，错误信息也很简洁。简而言之，您必须是一名业余的 SQL 程序员，并且对 HANA 列存储具备肯定的实操教训，能力纯熟应用 CE 函数编写良好的 SQLScript。
而后，2012 年时，随同着 HANA SPS04 的“Project Orange”这个我的项目的停顿，HANA 数据库曾经足够成熟，能够用于 SAP BW，但 BW 从未应用过 CE 性能。相同，BW 团队有本人的专有形式来应用 HANA。
这很快被证实是 BW 中的一个限度，导致一个新的概念诞生了：Calculation Scenario. 当初，当您在 BW 7.4 中编译 BW 对象时，会创立一个 HANA 视图，该视图能够通过 BW 的 OLAP 引擎拜访，也能够间接被 HANA 数据库拜访。两者是能够调换的，然而 CE 性能对于 BW 的需要来说限度太多了。
而后在 2013 年呈现了 HANA 上的 Business Suite。商务套件通过 OpenSQL 接口宽泛应用 ANSI SQL，并在 HANA SPS06 中首次亮相。因为 Business Suite 的编程形式，HANA 团队必须让 SQL 的执行效率比以前更高才行，并且 SQL 优化器进行了大量开发。从 HANA SPS06 开始，SQL 和 HANA Information Views 之间通常简直没有区别。
在此期间，超过一半的 SAP HANA 客户应用 BW，而 Business Suite 也是新增 go live 客户数量增长最快的 SAP 产品之一。这些产品自身都没有应用 CE 技术，因而 CE 技术失去的开发关注比拟无限，简直没有引入新性能。从 HANA SPS05 开始，就没有新的优化了。
从 HANA SPS07 开始，咱们发现 Graphical Calculation Views 总是比 CE Function 要快。在 HANA SPS08 中，咱们发现 SQL、Analytical View 和 Graphical Calculation Views 在很多状况下都有完全相同的 Execution plans. 这三者都具备雷同的运行时行为，抉择哪种模型只是您进行设计时的偏好问题。
事实上，能够将极其简单的视图创立为级联计算视图 (cascaded Calculation Views)，视图编译器将折叠(collapse) 和简化视图，并创立一组优化后的列投影、计算、向量连贯和联结作为单个计算场景。这种解决形式能够被视为 HANA 环境下进行建模的一个亮点。
请留神，脚本化计算视图 (Scripted Calculation View) 依然有其一席之地——您能够在 SQLScript 中调用业务函数、预测函数和其余存储过程对象。当然，在 HANA SPS09 中，也能够通过图形建模器来实现其中的一些工作。