9

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

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

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

4

4 回答 4

10

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

很久很久以前...

首次开发 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 视图”的问题。

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

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

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

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

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

您应该放弃计算视图吗？

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

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

这就是我的看法。

于 2020-01-12T01:16:13.310 回答
2

我要补充一点

  • 计算视图在语义上更丰富。SQL 视图不知道度量、维度、层次结构。https://blogs.sap.com/2019/08/26/what-is-the-difference-calcview-versus-sql-view/
  • 从执行计划的角度来看，差异越来越小。在 Hana 2.0 SP4 中，大多数图形计算视图在内部转换为单个 SQL 语句，由 SQL 引擎执行。因此，从这个意义上说，使用 CalcView 可以为您提供有关模型的附加信息以及 SQL 引擎的查询性能。

Lars 对 CDS 的解释是完美的。没有什么可添加的。

于 2020-02-21T16:50:05.370 回答
0

但是想象一下由于许可证有限（又名运行时版本）而无法创建表函数的情况。只保留脚本视图。

目前 Hana 工件相对于 CDS 的主要优势是能够在复杂情况下使用输入参数来优化资源和查询性能 - 当您的逻辑被推送到 DB 而不是 AS / app 时。但是很多原生 SQL 特性在图形视图中仍然不可用（例如 - exists, JOIN on BETWEEN），所以我认为 10 年后的 HANA 工件将变得“非常罕见”。

所以学习CDS语法:)

于 2020-02-27T21:41:20.583 回答
0

在任何媒体（StackOverflow、SAP 博客、文章、推特）上阅读 Lars 的文章或 pov 总是一种愉快的体验。

我只想指出，我在 SQL 脚本（SP、TF、SF）中遗漏的另一件事是信息视图具有的连接优化和 SQL 传播。

对我来说，这是对灵活模型的关注（除了仅与某些场景相关的动态连接），以提供一个视图，该视图将根据用户或应用程序请求的列来执行。对于语义使用，我可以简单地在信息视图中公开一个 TF 来添加一些内容。

你可以告诉我，CDS 有两个选项可用（连接优化、SQL 传播和注释），但对于高级或复杂的场景（CDS 中不存在窗口函数），以及非 SAP 开发人员，它会更简单，并且初学者的首选方法

于 2020-04-03T15:10:57.913 回答