SAP HANA CDS视图与计算视图与表函数

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实现编写应用程序，而与数据库的对话则留给了映射层/库（例如，O / R映射器）。这意味着，关于应用程序内容的知识（又名业务流程知识）在应用程序中得以传播。 在UI中有一些有关它的信息（标签，格式，可见性等），在应用程序对象模型中有一些信息（对象依赖项，层次结构，值域...），然后其中有一些信息在针对数据库的查询中。

这种分散的知识/定义使更改变得难以保持一致，这反过来又减慢了开发过程，反过来又延长了应用程序可以运行并产生积极成果之前的时间。

“实现价值的时间”

是这里正在优化的事物，因为这对于承诺“通过创新获得成功”的公司很重要。好，因此，现在CDS成为SAP提出的开发模型的一部分，并且几乎全部还涉及诸如模式演变和数据模型的部署等主题。实际上，它独立于ABAP品种CDS中所示的实际数据库平台。

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

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

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

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

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

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

CDS视图，如上所述，在查询运行时或优化方面都不是“特殊”的。 CDS视图之所以成为“事物”，主要是因为HANA SAP开始开发围绕

“虚拟数据模型”的开发模型（例如XS，XSA，CAM）。

那些想法是，表的结构通常是稳定的，并且随时间变化很小。在某种程度上，这是将数据输入表中的应用程序的[[“ write-schema”]。

“ read-schema”

在大多数情况下都与此不同。查询将归一化的数据重新组合为应用程序可以映射到对象的记录。这使应用程序与原始应用程序对数据的查看方式有所不同。使用“虚拟数据模型”，这些查询被烘焙到可以在整个应用程序中重复使用的有形开发工件（视图）中。实际上，可以将它们视为具有表的数据库，并以对应用程序有意义的方式呈现。 再次，如果这对您的应用程序开发是有益的，则取决于您的应用程序开发的外观。 您可以在没有CDS的情况下使用HANA吗？绝对是，CDS缺少很多领域（即，语法和功能映射到HANA功能的映射有限），但是确实有其优点。

您是否应该放弃计算视图？

如果现有的开发仍能满足其目的，我不一定会对其进行更改，但是计算视图当然是一个奇怪的开发对象。与仅坚持使用SQL相比，培训人们使用这些

和 SQL最有可能过于昂贵。

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