我认为你对潜在问题考虑过度了。正如你所说，表的大小很少超过百万条记录，这不足以将其视为大表。在我的应用程序中，我们有一些比这更大的表，但仍然能够很好地运行。此外，正如你所说，数据主要按天分类，因此理论上按日期对表进行分区是有意义的。这应该在一定程度上提高性能。但它也可能导致大量分区，这也会适得其反…… 阅读更多

投影节点基本上是一个图形计算视图。SAP HANA 不允许在图形计算视图中使用正则表达式来过滤数据。因此，如果你仍然需要使用图形计算视图（投影节点），则需要使用表函数或等效函数来过滤数据。

我认为不存在任何方法可以将表类型中列的列类型定义为数组。表类型是指具有预定义列数的行结构。因此，你可能需要重新考虑如何更改来自 .NET 应用程序的传入数据，以便将其用于你的 SAP HANA 项目。

我不确定是否有人能给你确切的答案，SAP 不是开源的，实现细节和位数除了创建者和少数其他人之外，许多人都不知道。如果我按照标准定义，对于存储，你需要数据长度的大小加上头信息字节数。因此，根据你的示例，它需要 9 + 2（用于头）= 11 的总存储空间。

我不确定 SAP HR 中是否存在以纯形式支持你的用例的内容。但是你可以通过在这里和那里进行一些更改来处理你提到的场景。SAP HR 中存在一个名为“合同”的信息类型，它存储员工的雇佣类型，例如永久性或合同制。你可以通过某些第三方服务来翻转员工类型的状态来处理这种类型。一旦员工辞职，然后将其重新雇用为合同工，但创建一个虚拟工资单，这样它就不会被选中…… 阅读更多

正如你所说，你正在使用热文件夹的概念，你需要确保在任何操作的任何时刻都使用了正确的线程。默认情况下，用于导入的线程数为一个。更技术一点地说，如果没有显式设置，impex.import.workers 线程为一个。由于在你的情况下文件很大，请确保你充分利用所有可用的核心。强烈建议在任何时间点上的最大线程数不应超过核心数的两倍。为了获得最佳工作效果，你可能需要…… 阅读更多

基本上，InfoStore 指的是关于对象和 BO 术语中的元数据——信息对象。信息对象基本上是 SAP 业务对象宇宙中的一个实体。它也可以是报表、用户或事件。例如：如果我们说的是员工，那么员工具有姓名、部门、职位、工资等元数据。当上下文在员工中时，InfoStore 会列出此元数据。因此，当你执行获取请求以获取 InfoStore 时，它会返回信息对象的元数据。

逻辑非常简单。你可以定义一个局部变量，用于存储所有组的总和。当你对每个组执行迭代时，可以将组级别的总和添加到局部变量中。我不建议使用代码，因为它非常基本和直接。

是的，存在等效项。你可以选择使用 SAP HANA 智能数据集成，也称为 SDI。它是 SAP 提供的标准数据集成产品。你不需要为此使用任何额外的基础设施，例如单独的服务器或其他。有很多博客和在线帮助可以帮助你开始使用 SDI。你也可以查看数据服务，但这太复杂了，对于提到的用途来说可能过于繁琐。

是的，PBO-PAI 触发提交，因此你的需求将失败。你需要更改当前实现以避免自动提交。