HANA CDS 视图与计算视图与 Table 函数
HANA CDS Views vs Calculation Views vs Table Functions
在 SAP HANA 中，我习惯于创建计算视图。
之前我了解到计算视图（编译后是列视图）优于数据库-SQL-视图。
现在有了 CDS-Views，我不确定情况是否仍然如此。特别是在性能方面。
现在 table 函数（取代了脚本计算视图）和 CDS 视图之间现在有什么区别？
好的，我认为这是一个需要一些背景知识才能回答的问题。
很久很久以前...
最初开发 SAP HANA 时，它大量重用了其他现有 SAP 产品（TREX、P*TIME、MaxDB、Business Warehouse Accelerator）的概念和技术。
高查询性能的基本要素之一是（现在也是）列存储数据存储，这在很大程度上来自 TREX/BWA 产品。反过来，这些产品是针对非常具体问题的解决方案（目录的全文搜索和来自 SAP Business Warehouse 数据仓库产品的分析查询的加速）。
特别是 BWA 用例反映在 SAP HANA 的 column views 中。由于支持 SAP BW 查询的用例有限，因此不需要一般的 SQL/relational 查询支持（例如，没有任意的连接链优化，没有 SQL 超出 SQL:92 的功能等），而其他, SAP BW 可以使用的相当奇特的功能（如 "vertical join"）被内置到查询 tool/engine 中（"engine" 显然是 SAP 开发人员中非常流行的术语）。
一旦 HANA 作为 运行 SAP BW 的平台被证明是成功的，下一步就是增加灵活性并制作更通用的平台，如 SAP Netweaver（SAP 业务解决方案产品 运行 的软件） on/with) 在 SAP HANA 上工作。现在，添加了 SQL 功能，这些功能需要查询优化器和执行的额外功能 "engines"。
查询优化必须灵活且快速，并且应该导致查询性能仍然优于现有 RDBMS 供应商的产品（已经存在 40 多年）。
显然，这是一个难题，并且抛出的是数据库开发的操作方面（扩展、解决方案部署、数据联合等）。
这导致了针对数据库开发不同方面的不同工具的重叠开发。
SQL 支持和底层 SQL 优化器变得更加强大，以至于（某些）SQL 查询可以与计算视图中建模的查询一样快或更快。由于这两个 "query frontends" 最终不得不与相同的内部数据结构（row/column 存储）进行对话，因此希望只有一个查询优化器可以支持所有不同的用例。
在 HANA 1 SPS11/12 附近的某个地方，大多数计算视图开始在内部 "unrolled" 以馈入通用优化器（这就是 "Execute in SQL Engine" 标志的含义）。
我想说，从那时起，使用计算视图的性能参数只在非常特殊的情况下成立。
我提到了重叠开发，CDS（核心数据服务）就是其中之一。这里的想法与 SQL 非常不同。虽然 SQL 为您提供 "the way to talk to the database"，但 CDS 希望为您的应用程序提供单一数据定义，供 UI、程序逻辑和数据 storage/query 执行使用。
SQL != CDS
这可能需要一些上下文（再次）：应用程序开发人员如何使用 SQL 数据库的主要使用模式是应用程序是以某种形式的 OO 实现和与 DB 的对话编写的留给映射layer/library（例如O/R-mappers）。这意味着，关于应用程序 的知识 （也称为业务流程知识）在应用程序中传播开来。
在 UI（标签、格式、可见性等）中有一些关于它的信息，其中一些在应用程序对象模型中（对象依赖性、层次结构、值域.. .) 然后其中一些在对数据库的查询中。
这种分散的 knowledge/definition 使得更改很难保持一致，这反过来又减慢了开发过程，进而延长了应用程序可以 运行 并交付一些积极成果的时间。
"Time-to-value" 是这里正在优化的东西，因为这对于承诺 "success through innovation" 的公司很重要。
好的，所以这个 CDS 东西现在是 SAP 提出的开发模型的一部分，几乎 en-passant 还解决了模式演变和数据模型部署等主题。事实上，它独立于实际的数据库平台，如 ABAP 种类的 CDS 中所示。
这对查询性能有何影响？不是真的。
CDS 的优势在于可以提供比 HANA 中更多的关于数据模型的信息 SQL。
具有基数声明的关联和连接（尽管现在已改装为普通 SQL）可以使优化器能够使用其他优化。然而，这里使用相同的优化器和相同的查询执行 "engines"。
因此，从（查询执行）性能的角度来看，只要不需要 CDS 没有语法的查询语义（例如某些 window 函数），它就没有太大区别).
CDS 的要点实际上是关于应用程序开发过程的性能，它是否适合您的开发方式实际上取决于您可以使用多少。
现在回答问题 "scripted calc view" vs. "table function" vs. "CDS view".
从 "what can I do with them functionally?" 的角度观察这些不同的对象类型将导致观察结果 "basically, the same"。
不同之处在于如何优化这些（脚本计算视图通常不能展开到要优化的全局查询中），以及一旦创建对象可以做什么。
Table 函数允许跨多个视图和查询非常轻松地重用。它们还提供了向函数提供参数的选项（类似于参数化视图），此外还允许命令式编码。
从功能上讲，table 函数是一种瑞士军刀；人们几乎可以用它们做任何事情，而且它们仍然可以成为全局查询优化的一部分。
CDS 视图，如上所述，在查询 运行 时间或优化方面没有什么 "special"。 CDS 视图 "a thing" 的主要原因是随着 HANA SAP 开始开发围绕 "virtual data models" 的开发模型（例如 XS、XSA、CAM）。
这些想法是 tables 的结构通常是 stable 并且随时间变化很小。
在某种程度上，这是将数据输入 table 的应用程序 "write-schema"。
"read-schema" 大多数时候与此不同。查询将规范化的数据重新组合成记录，应用程序可以将这些记录映射到对象中。这允许应用程序以不同于原始应用程序的方式查看数据。
使用 "virtual data models"，这些查询被烘焙到可以在整个应用程序中重复使用的有形开发工件（视图）中。事实上，这些可以被视为带有 table 的数据库，以对应用程序有意义的方式呈现。
再说一次，这是否对您的应用程序开发有益取决于您的应用程序开发情况。
你可以在没有 CDS 的情况下使用 HANA 吗？当然，CDS 有很多不足之处（即有限的语法和映射到 HANA 功能的功能），但它确实有其优点。
你应该放弃计算视图吗？
如果现有的开发仍能满足其目的，我不一定会更改它们，但计算视图肯定是一个奇怪的开发对象。与坚持使用 SQL 相比，培训人们使用那些 和 SQL 很可能过于昂贵。
就个人而言，我更喜欢基于代码的 SQL 开发（更好的可用工具，可以更轻松地与其他 DBMS 进行比较，不需要 WEB IDE/HANA Studio）。
基于 SQL 的开发唯一不提供的是 SAP 分析前端工具（SAC 和 BO）使用的扩展 annotations/semantic 信息——这些确实特定于 CDS 和信息模型（计算视图），但是几乎没有被其他分析工具使用。
这就是我的看法。
我要补充一点
- 计算视图在语义上更丰富。 SQL 视图不知道度量、维度、层次结构。 https://blogs.sap.com/2019/08/26/what-is-the-difference-calcview-versus-sql-view/
- 从执行计划的角度来看，差异越来越小了。在 Hana 2.0 SP4 中，大多数图形计算视图在内部转换为单个 SQL 语句，由 SQL 引擎执行。因此，从这个意义上说，使用 CalcView 可为您提供有关模型的附加信息以及 SQL 引擎的查询性能。
拉斯对CDS的解释很完美。没有什么可添加的。
但想象一下由于许可证有限（又名运行时版本）而无法创建 table 函数的情况。只使用脚本视图。
Hana 工件目前相对于 CDS 的主要优势是能够在复杂情况下使用输入参数来优化资源和查询性能——当您的逻辑被推送到 DB 而不是 AS / app 时。但是许多原生 SQL 特性在图形视图中仍然不可用（例如 - exists，JOIN on BETWEEN），所以我认为 10 年后 HANA 工件将变成 "very rare"。
所以学习 CDS 语法 :)
在任何媒体（Whosebug、SAP 博客、文章、推特）上阅读 Lars 的文章或观点总是一种愉快的体验。
我只想指出，我在 SQL 脚本（SP、TF、SF）中遗漏的另一件事是信息视图具有的连接优化和 SQL 传播。
对我而言，这是对灵活模型的关注（除了仅与某些场景相关的动态连接），以提供一个视图，该视图将根据用户或应用请求的列执行。
对于语义的使用，我可以简单地在信息视图中暴露一个 TF 来添加一些。
您可以告诉我，CDS 有两个可用选项（连接优化、SQL 传播和注释），但适用于高级或复杂的场景（window 函数在 CDS 中不存在），而且对于非 SAP 开发人员，它会更简单，是初学者的首选方法
在 SAP HANA 中，我习惯于创建计算视图。
之前我了解到计算视图（编译后是列视图）优于数据库-SQL-视图。 现在有了 CDS-Views，我不确定情况是否仍然如此。特别是在性能方面。
现在 table 函数（取代了脚本计算视图）和 CDS 视图之间现在有什么区别？
好的，我认为这是一个需要一些背景知识才能回答的问题。
很久很久以前...
最初开发 SAP HANA 时，它大量重用了其他现有 SAP 产品（TREX、P*TIME、MaxDB、Business Warehouse Accelerator）的概念和技术。
高查询性能的基本要素之一是（现在也是）列存储数据存储，这在很大程度上来自 TREX/BWA 产品。反过来，这些产品是针对非常具体问题的解决方案（目录的全文搜索和来自 SAP Business Warehouse 数据仓库产品的分析查询的加速）。
特别是 BWA 用例反映在 SAP HANA 的 column views 中。由于支持 SAP BW 查询的用例有限，因此不需要一般的 SQL/relational 查询支持（例如，没有任意的连接链优化，没有 SQL 超出 SQL:92 的功能等），而其他, SAP BW 可以使用的相当奇特的功能（如 "vertical join"）被内置到查询 tool/engine 中（"engine" 显然是 SAP 开发人员中非常流行的术语）。
一旦 HANA 作为 运行 SAP BW 的平台被证明是成功的，下一步就是增加灵活性并制作更通用的平台，如 SAP Netweaver（SAP 业务解决方案产品 运行 的软件） on/with) 在 SAP HANA 上工作。现在，添加了 SQL 功能，这些功能需要查询优化器和执行的额外功能 "engines"。 查询优化必须灵活且快速，并且应该导致查询性能仍然优于现有 RDBMS 供应商的产品（已经存在 40 多年）。 显然，这是一个难题，并且抛出的是数据库开发的操作方面（扩展、解决方案部署、数据联合等）。
这导致了针对数据库开发不同方面的不同工具的重叠开发。
SQL 支持和底层 SQL 优化器变得更加强大，以至于（某些）SQL 查询可以与计算视图中建模的查询一样快或更快。由于这两个 "query frontends" 最终不得不与相同的内部数据结构（row/column 存储）进行对话，因此希望只有一个查询优化器可以支持所有不同的用例。
在 HANA 1 SPS11/12 附近的某个地方，大多数计算视图开始在内部 "unrolled" 以馈入通用优化器（这就是 "Execute in SQL Engine" 标志的含义）。
我想说，从那时起，使用计算视图的性能参数只在非常特殊的情况下成立。
我提到了重叠开发，CDS（核心数据服务）就是其中之一。这里的想法与 SQL 非常不同。虽然 SQL 为您提供 "the way to talk to the database"，但 CDS 希望为您的应用程序提供单一数据定义，供 UI、程序逻辑和数据 storage/query 执行使用。
SQL != CDS
这可能需要一些上下文（再次）：应用程序开发人员如何使用 SQL 数据库的主要使用模式是应用程序是以某种形式的 OO 实现和与 DB 的对话编写的留给映射layer/library（例如O/R-mappers）。这意味着，关于应用程序 的知识 （也称为业务流程知识）在应用程序中传播开来。
在 UI（标签、格式、可见性等）中有一些关于它的信息，其中一些在应用程序对象模型中（对象依赖性、层次结构、值域.. .) 然后其中一些在对数据库的查询中。
这种分散的 knowledge/definition 使得更改很难保持一致，这反过来又减慢了开发过程，进而延长了应用程序可以 运行 并交付一些积极成果的时间。
"Time-to-value" 是这里正在优化的东西，因为这对于承诺 "success through innovation" 的公司很重要。
好的，所以这个 CDS 东西现在是 SAP 提出的开发模型的一部分，几乎 en-passant 还解决了模式演变和数据模型部署等主题。事实上，它独立于实际的数据库平台，如 ABAP 种类的 CDS 中所示。
这对查询性能有何影响？不是真的。
CDS 的优势在于可以提供比 HANA 中更多的关于数据模型的信息 SQL。
具有基数声明的关联和连接（尽管现在已改装为普通 SQL）可以使优化器能够使用其他优化。然而，这里使用相同的优化器和相同的查询执行 "engines"。
因此，从（查询执行）性能的角度来看，只要不需要 CDS 没有语法的查询语义（例如某些 window 函数），它就没有太大区别).
CDS 的要点实际上是关于应用程序开发过程的性能，它是否适合您的开发方式实际上取决于您可以使用多少。
现在回答问题 "scripted calc view" vs. "table function" vs. "CDS view".
从 "what can I do with them functionally?" 的角度观察这些不同的对象类型将导致观察结果 "basically, the same"。
不同之处在于如何优化这些（脚本计算视图通常不能展开到要优化的全局查询中），以及一旦创建对象可以做什么。
Table 函数允许跨多个视图和查询非常轻松地重用。它们还提供了向函数提供参数的选项（类似于参数化视图），此外还允许命令式编码。
从功能上讲，table 函数是一种瑞士军刀；人们几乎可以用它们做任何事情，而且它们仍然可以成为全局查询优化的一部分。
CDS 视图，如上所述，在查询 运行 时间或优化方面没有什么 "special"。 CDS 视图 "a thing" 的主要原因是随着 HANA SAP 开始开发围绕 "virtual data models" 的开发模型（例如 XS、XSA、CAM）。
这些想法是 tables 的结构通常是 stable 并且随时间变化很小。
在某种程度上，这是将数据输入 table 的应用程序 "write-schema"。
"read-schema" 大多数时候与此不同。查询将规范化的数据重新组合成记录，应用程序可以将这些记录映射到对象中。这允许应用程序以不同于原始应用程序的方式查看数据。
使用 "virtual data models"，这些查询被烘焙到可以在整个应用程序中重复使用的有形开发工件（视图）中。事实上，这些可以被视为带有 table 的数据库，以对应用程序有意义的方式呈现。
再说一次，这是否对您的应用程序开发有益取决于您的应用程序开发情况。
你可以在没有 CDS 的情况下使用 HANA 吗？当然，CDS 有很多不足之处（即有限的语法和映射到 HANA 功能的功能），但它确实有其优点。
你应该放弃计算视图吗？
如果现有的开发仍能满足其目的，我不一定会更改它们，但计算视图肯定是一个奇怪的开发对象。与坚持使用 SQL 相比，培训人们使用那些 和 SQL 很可能过于昂贵。
就个人而言，我更喜欢基于代码的 SQL 开发（更好的可用工具，可以更轻松地与其他 DBMS 进行比较，不需要 WEB IDE/HANA Studio）。
基于 SQL 的开发唯一不提供的是 SAP 分析前端工具（SAC 和 BO）使用的扩展 annotations/semantic 信息——这些确实特定于 CDS 和信息模型（计算视图），但是几乎没有被其他分析工具使用。
这就是我的看法。
我要补充一点
- 计算视图在语义上更丰富。 SQL 视图不知道度量、维度、层次结构。 https://blogs.sap.com/2019/08/26/what-is-the-difference-calcview-versus-sql-view/
- 从执行计划的角度来看，差异越来越小了。在 Hana 2.0 SP4 中，大多数图形计算视图在内部转换为单个 SQL 语句，由 SQL 引擎执行。因此，从这个意义上说，使用 CalcView 可为您提供有关模型的附加信息以及 SQL 引擎的查询性能。
拉斯对CDS的解释很完美。没有什么可添加的。
但想象一下由于许可证有限（又名运行时版本）而无法创建 table 函数的情况。只使用脚本视图。
Hana 工件目前相对于 CDS 的主要优势是能够在复杂情况下使用输入参数来优化资源和查询性能——当您的逻辑被推送到 DB 而不是 AS / app 时。但是许多原生 SQL 特性在图形视图中仍然不可用（例如 - exists，JOIN on BETWEEN），所以我认为 10 年后 HANA 工件将变成 "very rare"。
所以学习 CDS 语法 :)
在任何媒体（Whosebug、SAP 博客、文章、推特）上阅读 Lars 的文章或观点总是一种愉快的体验。
我只想指出，我在 SQL 脚本（SP、TF、SF）中遗漏的另一件事是信息视图具有的连接优化和 SQL 传播。
对我而言，这是对灵活模型的关注（除了仅与某些场景相关的动态连接），以提供一个视图，该视图将根据用户或应用请求的列执行。 对于语义的使用，我可以简单地在信息视图中暴露一个 TF 来添加一些。
您可以告诉我，CDS 有两个可用选项（连接优化、SQL 传播和注释），但适用于高级或复杂的场景（window 函数在 CDS 中不存在），而且对于非 SAP 开发人员，它会更简单，是初学者的首选方法