最近在SAP internal JAM community for HANA中的一次讨论使我了解到HANA SQL中添加的一项功能，该功能从HANA 1 SPS 12（不要询问修订版，只需检查最新版本）开始，分别是HANA 2 SPS 02（我们不谈论SPS 00和SPS 01，是吗？）："计算列"。

与许多其他函数一样，此功能的实现似乎是为了

勾选SQL标准符合性/竞争功能相等的框和为核心数据服务（CDS）提供一个功能的SQL实现（所有HANA CDS函数都以某种方式映射到SQL功能，这意味着不能用CDS来表达比SQL更多的内容）

最初，我认为"计算列？我们已经有一段时间了！"与"GENERATED ALWAYS"（GC）列相关联，但这不是"calculated columns"（从这里开始的CC）是什么。CCs不存储任何值，而是在查询时计算值。

它们是Oracle的"virtual column"和MS SQL Server的"computed column"对应的功能。或者，更准确地说，HANA特性CC和GC组合映射到其他DBMS的各自特性，因为它们提供了将计算值作为命令选项持久化的选项（对我来说是有意义的）。如上所述，SQL标准（2003）包含计算列作为可选功能，这可能就是为什么所有这些DBMS产品中都存在这种模糊功能的原因。

虽然我了解GC的使用场景，企业系统开发，其中存储了计算结果-预计算-但有些事关性能和以后的重用-我不太确定CC的用例。上述JAM讨论中的SAP同事非常喜欢它们，因为它允许在不使用视图的情况下指定计算列。这样，就可以在非常接近表本身的地方定义只需一个表的列就可以构建的公共数据转换。这听起来是一件好事。

现在，我对此有了不同的看法。

假设我运行一个普通的旧表

我的期望是HANA为我提供可见表列的当前有效内容。我肯定不希望在解释计划中找到任何计算。但对于基于表达式的列，这正是我得到的：

当然，这种计算增加了语句处理的运行时和内存使用，并将在更复杂的场景中更改查询计划。

当我尝试索引列时，同样的惊喜会出现：

或者当我尝试基于此列进行分区时

索引和分区是Oracle和mssqlserver中CC特性的主要用例。HANA不支持这些用例，所以剩下的就是不必创建视图作为主要的好处。

显然有人可能会说：当我查询基表时，HANA不应该计算表达式的期望是错误的。从SQL 2003开始（14年了！），它不再是正确的。所以，去改变你的期望吧！

公平的要求，云服务器特价，但大多数用户没有这种期望。"哑"基表的概念太强了，像CCs和触发器之类的东西很容易被忽略。问题就是从这里开始的：当对行为的期望是错误的时，物联网公司排名，这通常意味着错误、错误的决定和浪费的时间和精力。

后来遇到使用CCs的表的穷人（甚至可能是忘记了这个表包含CCs的同一个开发人员）不能从"看"表中分辨出来哪些列是真正的"基本"列，哪些是计算列。它不会显示在表定义UI中，也不会显示在从选择前5*中。只有当这个人深入挖掘并检查CDS源代码或HANA系统表（表\列）并真正查找此设置时，才能看到此信息。

我不喜欢这种惊喜，而是有一个包含必要表达式和转换的基表和消费视图。我不仅可以在这样的消费视图中创建更复杂的表达式，而且我还有更好的机会了解数据存储的位置和数据计算的位置。

我想到的CCs的另一个用例是在DB级别更改数据模型，而应用程序保持不变。这种更改只能用于从表中读取的应用程序。一旦有人试图更改列，这将导致一个错误。

所以，你看，我真的很难找到一个好的理由使用这个功能。那你呢？你有没有遇到过这样一个场景：这曾经是/将会是绝对的救命稻草？何时何地使用？为什么？

请在评论部分分享您与CCs或虚拟/专栏的经验。

好了，万云，现在就开始！

干杯，Lars

p.s.我创建了我的user\u info表，它基于一个包含虚构电子邮件地址的表：

添加计算列是直接的：

注意：计算部分只允许使用HANA表达式。没有函数调用或复杂的SQL语句。

，淘客放单平台