SAP HANA 列出层次结构第 3 级中的所有材料
SAP HANA List all materials in 3rd level of a hierarchy
SAP HANA 1.0.
图形计算视图。
两个问题：
使用 Hana 建模工具：
1) 我如何编写一个图形计算视图，它可以提供 CN1003 产品层次结构中的所有 material 并同时显示 CN1003 的文本描述？
我知道我可以使用 MARA.PRDHA 获取 material 的层次结构，使用 T179T 获取层次结构的文本；但似乎我需要生成一个计算列以仅包含前 6 个字符然后进行过滤。但最佳做法表明不要在计算列上进行过滤。那么这里正确的方法是什么？有没有我可以加入的 table 来打破层次结构？这样我就可以过滤 'CN' 和“1003”的前两段？
例如：
马拉
+-------+--------------+
| MATNR | PRDHA |
+-------+--------------+
| 12345 | CN1003 |
| 12346 | CN10034231 |
| 12347 | CN1003423112 |
| 12348 | CN1002 |
| 12349 | FK1003 |
+-------+--------------+
T179T
+--------------+----------+
| PRODH | VTEXT |
+--------------+----------+
| CN1003 | Widgets |
| CN1002 | Magnets |
| CN10034231 | Tall |
| CN1003423112 | Red |
| FK1003 | Minerals |
+--------------+----------+
预期结果：
+-------+---------+
| MATNR | VTEXT |
+-------+---------+
| 12345 | Widgets |
| 12346 | Tall |
| 12347 | Red |
+-------+---------+
2) 在图形计算视图中：将 varchar(8) 字段的语义类型设置为最新的目的是什么？我认为这会将 "date" varchar(8) 字段转换为日期数据类型，以供 Calculation 视图中的 Universe 使用；但显然不是。因此，我是否必须使用计算列将此非日期日期转换为实际日期数据类型，这不是违反最佳实践，因为我再次在计算列上进行过滤吗？那么如何将我的字符串日期设置为执行此操作的日期呢？或者我是否应该要求我的用户输入一个字符串日期，这在我的报告 BI 世界中似乎是一个错误的 UI 选择。为什么 Hana 不直接将日期存储为日期！？
这是两个写得很好的问题 - 谢谢。
对于第二个问题，答案很简单：计算视图中字段的语义属性实际上只是前端工具的一个指标到 "do the right thing" 吧。它主要由 SAP 前端工具和 AFAIK 使用，并没有真正被任何其他工具广泛使用。
至于日期数据存储：这是 SAP ABAP 特质 几十年来一直沿用的设计决策。它允许 SAP ABAP 在任何支持的 DBMS 上存储 date/time 信息，并保证以完全相同的方式和明确定义的语义取回数据。
ABAP 数据类型称为 DATS 和 TIMS 并以字符格式表示 date/time 信息。
如果您想启用基于实际日期（或什至基于 date/time 信息的层次结构）的过滤，那么 SAP 工具（如 SAC）支持开箱即用。或者，您可以提供一个值帮助视图，该视图专门为选择执行数据类型转换，并将过滤条件转换回 DATS/TIMS 格式。
这样，与其余查询处理相比，转换工作量最少。
关于第一个问题，我不确定我是否看到这里的问题。
可以通过简单的文本连接（或常规连接）将文本与层次结构标识符进行匹配。
您的过滤可以基于文本 table 轻松地（再次）在值帮助视图上工作，该文本向最终用户呈现分解的（双关语）字符串部分。
根据选择，从 text-table 到 parts-table 的连接将只包含选定的记录。
同样，转换工作只在较小的 table 上完成一次（table 和较小的词典）。
没有硬性规定必须预先计算 SAP HANA 中的每个数据转换。事实恰恰相反。通过值助手视图中提到的临时转换，您可以避免在大型 table 上进行不必要的转换，而无需额外的预计算结构。
我可以提供的另一个评论是，根据我的经验，在确定实际性能问题之前引入预先计算的列和索引确实没有任何意义。
然而，考虑何时、何地以及为什么数据将被转换和相应地设计确实是值得的。
SAP HANA 1.0.
图形计算视图。
两个问题：
使用 Hana 建模工具：
1) 我如何编写一个图形计算视图，它可以提供 CN1003 产品层次结构中的所有 material 并同时显示 CN1003 的文本描述？
我知道我可以使用 MARA.PRDHA 获取 material 的层次结构，使用 T179T 获取层次结构的文本；但似乎我需要生成一个计算列以仅包含前 6 个字符然后进行过滤。但最佳做法表明不要在计算列上进行过滤。那么这里正确的方法是什么？有没有我可以加入的 table 来打破层次结构？这样我就可以过滤 'CN' 和“1003”的前两段？
例如： 马拉
+-------+--------------+
| MATNR | PRDHA |
+-------+--------------+
| 12345 | CN1003 |
| 12346 | CN10034231 |
| 12347 | CN1003423112 |
| 12348 | CN1002 |
| 12349 | FK1003 |
+-------+--------------+
T179T
+--------------+----------+
| PRODH | VTEXT |
+--------------+----------+
| CN1003 | Widgets |
| CN1002 | Magnets |
| CN10034231 | Tall |
| CN1003423112 | Red |
| FK1003 | Minerals |
+--------------+----------+
预期结果：
+-------+---------+
| MATNR | VTEXT |
+-------+---------+
| 12345 | Widgets |
| 12346 | Tall |
| 12347 | Red |
+-------+---------+
2) 在图形计算视图中：将 varchar(8) 字段的语义类型设置为最新的目的是什么？我认为这会将 "date" varchar(8) 字段转换为日期数据类型，以供 Calculation 视图中的 Universe 使用；但显然不是。因此，我是否必须使用计算列将此非日期日期转换为实际日期数据类型，这不是违反最佳实践，因为我再次在计算列上进行过滤吗？那么如何将我的字符串日期设置为执行此操作的日期呢？或者我是否应该要求我的用户输入一个字符串日期，这在我的报告 BI 世界中似乎是一个错误的 UI 选择。为什么 Hana 不直接将日期存储为日期！？
这是两个写得很好的问题 - 谢谢。
对于第二个问题，答案很简单：计算视图中字段的语义属性实际上只是前端工具的一个指标到 "do the right thing" 吧。它主要由 SAP 前端工具和 AFAIK 使用，并没有真正被任何其他工具广泛使用。
至于日期数据存储：这是 SAP ABAP 特质 几十年来一直沿用的设计决策。它允许 SAP ABAP 在任何支持的 DBMS 上存储 date/time 信息，并保证以完全相同的方式和明确定义的语义取回数据。
ABAP 数据类型称为 DATS 和 TIMS 并以字符格式表示 date/time 信息。
如果您想启用基于实际日期（或什至基于 date/time 信息的层次结构）的过滤，那么 SAP 工具（如 SAC）支持开箱即用。或者，您可以提供一个值帮助视图，该视图专门为选择执行数据类型转换，并将过滤条件转换回 DATS/TIMS 格式。
这样，与其余查询处理相比，转换工作量最少。
关于第一个问题，我不确定我是否看到这里的问题。 可以通过简单的文本连接（或常规连接）将文本与层次结构标识符进行匹配。 您的过滤可以基于文本 table 轻松地（再次）在值帮助视图上工作，该文本向最终用户呈现分解的（双关语）字符串部分。 根据选择，从 text-table 到 parts-table 的连接将只包含选定的记录。
同样，转换工作只在较小的 table 上完成一次（table 和较小的词典）。
没有硬性规定必须预先计算 SAP HANA 中的每个数据转换。事实恰恰相反。通过值助手视图中提到的临时转换，您可以避免在大型 table 上进行不必要的转换，而无需额外的预计算结构。
我可以提供的另一个评论是，根据我的经验，在确定实际性能问题之前引入预先计算的列和索引确实没有任何意义。
然而，考虑何时、何地以及为什么数据将被转换和相应地设计确实是值得的。