在SAP HANA中，我用于创建计算视图。
以前我了解到计算视图(编译后为列视图)比数据库SQL视图更受欢迎。现在有了CDS视图，我不确定情况是否仍然如此。尤其是在性能方面。
此外，现在表函数(取代了脚本计算视图)和CDS视图之间的区别是什么？
好的，我认为这是一个需要一些背景知识才能回答的问题。
很久很久以前
当SAP HANA首次开发时，它大量重用了其他现有SAP产品(TREX、p*TIME、MaxDB、Business Warehouse Accelerator)的概念和技术
高查询性能的基本要素之一是(现在也是)列存储数据存储，它在很大程度上来自TREX/BWA产品。反过来，这些产品解决了非常具体的问题(全文搜索目录和加快SAP Business Warehouse数据仓库产品的分析查询)
特别是BWA用例反映在SAP HANA的列视图中。由于支持SAP BW查询的用例有限，不需要通用的SQL/关系查询支持(例如，不需要任意的连接链优化，不需要SQL以外的SQL功能：92等)，而SAP BW可以使用的其他非常奇特的功能(如"垂直连接")则内置在查询工具/引擎中("引擎"显然是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！=cd
这可能需要一些上下文：应用程序开发人员如何使用SQL数据库的一个主要使用模式是，应用程序是以某种OO实现的形式编写的，而与数据库的对话则留给映射层/库(例如O/R映射器)。这意味着，应用程序的相关知识(也称为业务流程知识)将在应用程序中展开。
UI中有一些关于它的信息(标签、格式、可见性等)，其中一些信息在应用程序对象模型中(对象依赖关系、层次结构、值域等)，还有一些信息在针对数据库的查询中。
这种分散的知识/定义使得很难使更改保持一致，这反过来又减缓了开发过程，并延长了应用程序运行并产生一些积极结果的时间
"实现价值的时间">是这里正在优化的内容，因为这对于承诺"通过创新获得成功"的公司来说很重要。
好吧，这个CDS现在是SAP提出的开发模型的一部分，几乎同时也涉及到模式进化和数据模型部署等主题。事实上，它独立于实际的数据库平台，如ABAP变体的CDS所示。
这是如何恢复查询性能的？事实并非如此
CDS的优势在于，与HANASQL相比，可以提供更多关于数据模型的信息
具有基数声明的关联和联接(尽管现在已改进为普通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和信息模型(计算视图)所特有的，但几乎没有被其他分析工具使用。
这就是我的看法。
我会添加
- 计算视图在语义上更丰富。SQL视图不知道度量值、维度和层次结构。https://blogs.sap.com/2019/08/26/what-is-the-difference-calcview-versus-sql-view/
- 从执行计划的角度来看，差异越来越小。在Hana2.0SP4中，大多数图形计算视图都在内部转换为一条SQL语句，由SQL引擎执行。因此，从这个意义上说，使用CalcView可以为您提供有关模型的附加信息以及SQL引擎的查询性能
Lars对CDS的解释是完美的。没有什么可补充的。
但想象一下，由于许可证有限(也称为运行时版本)，您无法创建表函数的情况。只需使用脚本视图即可。
目前，Hana工件相对于CDS的主要优势是能够在复杂情况下使用输入参数来优化资源和查询性能——当您的逻辑被推送到DB而不是AS/app时。但是许多原生SQL特性在图形视图中仍然不可用(例如-存在，在BETWEEN上加入)，所以我认为10年后HANA工件将变得"非常罕见"。
因此，学习CDS语法：)
在任何媒体(StackOverflow、SAP博客、文章、推特)上阅读Lars的文章或pov总是一种愉快的体验。
我只想指出，我从SQL脚本(SP、TF、SF)中错过的另一件事是Information View所具有的联接优化和SQL传播。
对我来说，这是对灵活模型的关注(除了只与某些场景相关的动态联接)，以提供一个视图，该视图将根据用户或应用程序将请求的列执行。对于语义的使用，我可以简单地在信息视图中公开一个TF来添加一些。
你可以告诉我，CDS有两种选择(连接优化、SQL传播和注释)，但对于高级或复杂的场景(CDS中不存在窗口函数)，以及非SAP开发人员，它将更简单，是初学者的首选方法