好吧，您以很明显想要得到答案的方式提出问题：

"是的，您的自动SQL视图方法是更好，更有效的方法。"

这是您的陈述所暗示的，每种方法将花费多少精力（SQL：很少，CalcView：很多），结果将是相同的。

那你为什么要问？

除了结果偏见之外，您没有提供任何实际背景来对任何一种选择进行有意义的评估，更不用说其他可能混合的情况了。

同时使用这两种方法，我可以告诉您，以后很难维护，理解和调试生成的视图。 当您认为生成视图的效率有所提高时，通常很难把握所得数据模型的复杂性。 那时，人们希望使用小的，独立的逻辑位，并带有对注释和注释的工具支持以及对数据源和处理步骤的良好命名。 嘿，那是图形计算视图！

当生成更大的开发工件集时，经常需要将它们一致地部署到不同的系统（dev，qa，prod ...）中-在HANA存储库对象中可以做到这一点。 您打算如何精确地自动创建它们？ 使用REST接口？ 好的电话，但是您已经有一个可行的实现方案了吗？

我并不是说您应该使用图形计算视图或简单的SQL视图或其他任何专门的视图。 我的意思是：当您提出问题时，以不回答问题的方式提出问题，并以允许理解问题和上下文的方式提出问题，以便可以对选项进行实际评估。

干杯

Lars

你好拉尔斯，

非常感谢您的提示。 那真的有帮助！ 我正在使用的szenario与您对医院数据的描述非常相似：（a）具有给定XML模式的XML数据，（b）转换为关系结构，（c）满足给定结构的视图。 从体系结构的角度来看，不需要这些视图（在此处的szenario中），因为您可以在将数据初始加载到关系表的过程中，将所有字符串解析，转换，拆分...放入XML处理中。 不幸的是，由于所用工具的限制，这是不可能的（那里没有真正的XML支持）。 因此，我们尝试使用（任何一种）视图来解决该问题。

普通的SQL视图正在同时工作-但我同意你的看法：仅了解这些视图还不够。 您需要了解如何生成它们。 他们自己的观点可能很容易理解，而生成它们的程序却并非如此。

基于SQL视图的实用计算视图即使有很多，也很容易生成。 您只需要视图的名称和一些其他单击即可构建它们（因为SQL视图已经给出了目标结构）。 但是它们没有额外的好处，因为它们取决于SQL视图中的"逻辑"。 现在，我也尝试将其作为第二种解决方案。

我将尝试设置您的XML想法（作为第三种解决方案）。 也许可以将其用作进一步手动编辑通用计算视图的起点，而无需中间SQL层（SQL视图）。 再次将有一个程序（用于生成XML文件）。 再一次，转换逻辑将在该程序内（再一次，这可能不容易理解）。 但是结果很容易理解，因此不需要进一步维护此XML生成器。

再次：非常感谢！ （我的下一个问题会问一个更好的方法-我保证。）

最诚挚的问候，

基督徒

嗨克里斯坦，

首先，好消息是，HANA的最新增强功能使您可以在查询执行性能方面使用数据库目录视图，这几乎可以与其他用法相提并论。

但是，您确实要花掉整个过程，而失去与正式开发协议相关的某些功能和控制，例如，集成安全性（分析特权），版本管理，程序包管理（以及相关的管理控制） ），多租户（客户端），基于会话的默认设置（例如语言），内置分析功能（例如货币转换），内容标签，层次结构，联合修剪等。请记住，内容修改本身是通过 包。

我同意Lars的说法，即虽然生成这些对象很简单，但是维护它们是一项艰巨的任务。 并且为"简单"任务创建所有图形（甚至脚本）视图也不是很费时。

如果您打算使用上面提到的任何"应用功能"，那么使用HANA中的相同功能，而不是使用外部解决方案会更好-这将提供更好的企业功能。

此致

Kapil