SAP HANA CDS-Views vs Calculation Views vs Table Functions

Question

在 SAP HANA 中，我习惯于创建计算视图。

之前我了解到计算视图（编译后是列视图）比数据库 SQL 视图更受欢迎。现在有了 CDS-Views，我不确定是否仍然如此。尤其是在性能方面。

现在表函数（取代脚本计算视图）和 CDS 视图之间的区别是什么？

Answer 1

好的，我认为这是一个需要回答一些背景知识的问题。

很久很久以前...

首次开发 SAP HANA 时，它大量重用了其他现有 SAP 产品（TREX、P*TIME、MaxDB、Business Warehouse Accelerator）的概念和技术。
高查询性能的基本要素之一是（现在也是）列存储数据存储，它大部分来自 TREX/BWA 产品。反过来，这些产品一直是非常具体问题的解决方案（目录的全文搜索和来自 SAP Business Warehouse 数据仓库产品的分析查询的加速）。
特别是 BWA 用例反映在列视图中SAP HANA。由于支持 SAP BW 查询的用例有限，不需要一般的 SQL/关系查询支持（例如，不需要任意连接链优化，没有 SQL 以外的 SQL 特性：92 等），而其他相当奇特的特性（如“垂直join”）可以被 SAP BW 使用，被内置到查询工具/引擎中（“引擎”显然是 SAP 开发人员非常流行的术语）。

一旦 HANA 作为运行 SAP BW 的平台被证明是成功的，下一步就是增加灵活性并使更通用的平台，如 SAP Netweaver（运行 SAP 业务解决方案产品的软件）在 SAP HANA 上运行。现在，添加了 SQL 功能，这些功能需要来自查询优化器和执行“引擎”的附加功能。查询优化必须灵活且快速，并且查询性能仍将优于现有 RDBMS 供应商的产品（已有 40 多年的历史）。显然，这是一个难题，抛出是数据库开发的操作方面（扩展、解决方案部署、数据联合等）。

这导致了针对 DB 开发不同方面的不同工具的重叠开发。
SQL 支持和底层 SQL 优化器变得更加强大，以至于（某些）SQL 查询可能与在计算视图中建模的查询一样快或更快。由于这两个“查询前端”最终都必须与相同的内部数据结构（行/列存储）对话，因此希望只有一个查询优化器，它可以支持所有不同的用例。
在 HANA 1 SPS11/12 附近的某个地方，大多数计算视图开始在内部“展开”以提供给通用优化器（这就是“在 SQL 引擎中执行”标志的含义）。

我想说，从那时起，使用计算视图的性能论点只适用于非常特定的情况。

我提到了重叠的发展，CDS（核心数据服务）就是其中之一。这里的想法与 SQL 非常不同。虽然 SQL 为您提供了“与数据库对话的方式”，但 CDS 想要为您的应用程序提供一个单一的数据定义，供 UI、程序逻辑和数据存储/查询执行使用。

SQL != CDS

这可能需要一些上下文（再次）：应用程序开发人员如何使用 SQL 数据库的一个主要使用模式是应用程序是以某种形式的 OO 实现编写的，并且与数据库的对话留给映射层/库（例如 O/R 映射器）。这意味着，应用程序是关于什么的知识（又名业务流程知识）在应用程序中展开。

在 UI 中有一些关于它的信息（标签、格式、可见性……），其中一些在应用程序对象模型中（对象依赖关系、层次结构、值域……），然后一些在对数据库的查询。

这种分散的知识/定义使更改难以保持一致，这反过来又会减慢开发过程，进而延长应用程序可以运行并交付一些积极成果的时间。
“实现价值的时间”是这里优化的东西，因为这对于承诺“通过创新取得成功”的公司很重要。

好的，所以这个 CDS 的东西现在是 SAP 提出的开发模型的一部分，几乎enpassant 还解决了模式演化和数据模型部署等主题。事实上，它独立于实际的数据库平台，如 ABAP 品种的 CDS 所示。

这如何导致查询性能？它不是真的。

CDS 的优势在于，与 HANA SQL 中可能提供的信息相比，它可以提供更多有关数据模型的信息。
带有基数声明的关联和连接（尽管现在改造成普通 SQL）可以使优化器能够使用额外的优化。然而，这里使用了相同的优化器和相同的查询执行“引擎”。

因此，从（查询执行）性能的角度来看，只要不需要 CDS 没有语法（例如某些窗口函数）的查询语义，它就不会产生太大差异。

CDS 的重点实际上是关于应用程序开发过程的性能，它是否与您的开发方式相得益彰，实际上取决于您可以使用多少。

现在是“脚本化计算视图”与“表函数”与“CDS 视图”的问题。

从“我可以用它们做什么功能”的角度来看待这些不同的对象类型？将导致观察结果“基本上相同”。区别在于如何优化这些（脚本化的 calc 视图通常不能展开到要优化的全局查询中），以及一旦创建对象可以做什么。
表函数允许在多个视图和查询之间非常轻松地重用。它们还提供了向函数提供参数的选项（类似于参数化视图），此外还允许进行命令式编码。从功能上讲，表功能是一把瑞士军刀；人们几乎可以用它们做任何事情，而且它们仍然可以成为全局查询优化的一部分。

如上所述，CDS 视图在查询运行时或优化方面没有什么“特别”之处。CDS视图之所以成为“东西”的主要原因是SAP随着HANA开始开发围绕“虚拟数据模型”的开发模型（如XS、XSA、CAM）。

这些想法是表的结构通常是稳定的，并且随着时间的推移变化很小。
在某种程度上，这是将数据输入表的应用程序的“写入模式”。
在“读模式”是最从时间不同。查询将规范化数据重新组合成应用程序可以映射到对象的记录。这允许应用程序以不同于原始应用程序的方式查看数据。通过“虚拟数据模型”，这些查询被烘焙成可在整个应用程序中重用的有形开发工件（视图）。事实上，这些可以被视为数据库及其表，以对应用程序有意义的方式呈现。

再说一次，这是否对您的应用程序开发有益取决于您的应用程序开发方式。

你可以在没有 CDS 的情况下使用 HANA 吗？当然，CDS 在很多方面都缺乏（即有限的语法和映射到 HANA 特性的特性），但它确实有它的优点。

您应该放弃计算视图吗？

如果现有的开发仍然服务于它们的目的，我不一定会改变它们，但计算视图肯定是一个奇怪的开发对象。与仅坚持使用 SQL 相比，培训人员使用这些和SQL 很可能过于昂贵。

就个人而言，我更喜欢基于代码的 SQL 开发（更好的工具可用，可以更轻松地与其他 DBMS 进行比较，不需要 WEB IDE/HANA Studio）。
基于 SQL 的开发唯一不提供的是 SAP 分析前端工具（SAC 和 BO）使用的扩展注释/语义信息 - 这些确实特定于 CDS 和信息模型（计算视图），但其他分析工具几乎不使用.

这就是我的看法。