view - SAP HANA CDS View 与计算 View 与表函数

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：92以外的SQL功能等），而其他一些比较奇怪的功能（例如“垂直” SAP BW可以使用的“ join”（连接）内置到查询工具/引擎中（“引擎”显然是SAP开发人员非常流行的术语）。

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

这导致针对数据库开发不同方面的不同工具的重叠开发。
SQL支持和基础的SQL优化器变得更加强大，以至于（某些）SQL查询可能比在计算视图中建模的查询快或快。而且，由于这两个“查询前端”最终都必须与相同的内部数据结构（行/列存储）进行通信，因此希望只有一个查询优化器，它将支持所有不同的用例。
在HANA 1 SPS11 / 12周围的某个地方，大多数计算视图开始在内部“展开”以馈送到通用优化器中（这就是“在SQL引擎中执行”标志所针对的意思）。

我要说，从那时起，使用计算视图的性能参数仅在非常特殊的情况下成立。

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

SQL！= CDS

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

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

如此分散的知识/定义使得很难进行一致的更改，从而减慢了开发过程，进而延长了应用程序可以运行并产生积极成果的时间。
“实现价值的时间”是这里要优化的事情，因为这对于承诺“通过创新获得成功”的公司很重要。

好的，因此，CDS现在已成为SAP提出的开发模型的一部分，并且几乎全部还涉及诸如模式演变和数据模型的部署等主题。实际上，它独立于ABAP品种CDS中所示的实际数据库平台。

这如何导致查询性能恢复？并非如此。

CDS的优势在于，与HANA SQL相比，CDS可以提供​​有关数据模型的更多信息。
与基数声明的关联和联接（尽管现在已改型为普通SQL）可以使优化器使用其他优化。但是，这里使用相同的优化器和相同的查询执行“引擎”。

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

CDS的重点实际上是关于应用程序开发过程的性能，以及它是否与您的开发方式很好地结合，实际上取决于您可以使用多少性能。

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

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

如上所述，就查询运行时或优化而言，CDS视图并不是“特殊”的。 CDS视图是“一件事”的主要原因是，随着HANA SAP开始开发围绕“虚拟数据模型”的开发模型（例如XS，XSA，CAM）。

这样做的想法是，表的结构通常是稳定的，并且随时间变化很小。
在某种程度上，这是将数据输入表中的应用程序的“写入模式”。
大多数时候，“读取模式”与之不同。查询将归一化的数据重新组合为应用程序可以映射到对象的记录。这使应用程序与原始应用程序对数据的查看方式有所不同。
使用“虚拟数据模型”，这些查询被烘焙到可以在整个应用程序中重复使用的有形开发工件（视图）中。实际上，可以将它们视为具有表的数据库，并以对应用程序有意义的方式呈现。

再次说明，这是否对您的应用程序开发有利，取决于您的应用程序开发外观。

您可以在没有CDS的情况下使用HANA吗？的确，CDS缺少很多领域（即，语法和功能映射到HANA功能的映射有限），但是确实有其优点。

您应该放弃计算视图吗？

如果现有的开发仍能满足其目的，我就不必对其进行更改，但是计算视图无疑是一个奇怪的开发对象。与仅仅坚持使用SQL相比，培训人员使用这些和SQL的成本极高。

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

这就是我的看法。