Abap 运行时类型服务（RTT）是否使用数据库获取数据描述？

问题

像

这样的方法是通过数据来描述数据

，

获取数据字段列表

，

获取组件

（属于

cl\u abap\u typedescr

和类似的），从数据库中检索数据还是在应用服务器上生成数据

我查看了这些类，所有的一些方法（大概是填充缓存的方法）似乎都是以非标准的方式提取数据的（

METHOD…BY KERNEL MODULE…

），而其他方法则是从缓存中提取数据的。我想知道如果没有缓存，它是如何被提取的

谷歌也没有给我任何关于这个话题的具体信息

某些上下文，以防细节变得相关

我一直在研究为一些泛型类实现动态select子句生成（用星号代替S/4HANA中基于列的处理，希望减少对DB的压力）

由于这些类中的大多数都将数据检索到字典类型的结构中，所以我想我可以使用运行时类型服务（RTT）的类型描述来获取字段列表，并根据目标结构动态生成select子句

在大多数情况下，我可以通过实现静态变量（并且每个会话只处理一次）来解决性能损失（如果有的话），但我遇到过类似的情况，其中静态变量不是一个选项（在未知类型上进行处理）我不得不放弃这个想法，因为我不确定如果调用这些方法会对峰值性能产生怎样的影响，比如说每个会话调用30次

编辑（只是一段代码，以避免进一步的混淆，从而导致没有实质内容的居高临下的评论）：

---

我不能确定是否有最新的ABAP版本，但ABAP字典内容（数据字典又称为“DDIC”）源自数据库表DDNTT和DDNTF（也称为“nametab”，其元素称为“数据库运行时对象”），在DDIC对象激活期间填充（表等等，这些表是DD02L、DD03L，如@icbytes所说，等等）

当查询它们时，它们也会被传输并保存在每个应用服务器内存中。该内存称为名称选项卡缓冲区。当缓冲区已满时，最新的数据将替换最旧的数据

不知道性能如何，但毫无疑问，与您随后所做的选择相比，它是可以忽略的

关于RTT，还有一件事，始终使用GET_*方法，而不是CREATE_*方法，因为它们速度更快（它们的行为稍有不同，但通常只有经验丰富的开发人员才需要使用后者）

---

如果您愿意，您可以添加另一层内存，但我想这不值得（花费更多的开发人员时间+消耗更多的内存，而不是没有大的性能改进）.

感谢您的输入。如果我不够清楚，我很抱歉，但我所做的是动态选择，但使用RTT动态形成字段/列列表（基于目标结构）一个select子句。你介意澄清一下是什么让你说我在重写RTTS吗？好吧，明确定义的问题是解决方案的一半。如果你想动态形成一个目标结构，将DB数据选择到其中，RTTS是完全可能的（不知道你需要什么RTTS实现细节）。只需重新编写您的问题，详细描述您的任务，并给出您的代码段/工作/到目前为止的进度。如果您还动态创建绑定/加入子句，那就更有趣了。在您的情况下，看起来您只是想从一个表中选择一些特定字段。我做了几次。谈到细节，RTT是否正在从db本身检索ddic定义，但您不确定，请获取表DD02L或DD03L的所需字段。但在大多数情况下，您可以信任RTT，获取组件，创建目标结构，然后创建表，然后使用comptab创建select子句字符串。查看structdescr->get_ddic_FIELD_LIST。我考虑过动态连接选择，但似乎更麻烦，我想知道的是RTTS方法的速度是否值得担心。这么说，我的一个想法是使用

按名称描述（而不是按数据描述），传递结构名称表（而不是结构本身）并基于DB表名和目标structures中的名称之间的匹配进行构建。对于重叠字段（其中必须在select中指定表）在第三个表中强制手动映射。这很复杂，但最终实现了目标。@icbytes只是对连接字段绑定的更新。我做了一个，但调用最终需要一大组参数（以处理数据库表和深层结构的模糊字段名）。这种方法的用途非常有限。正如我在一个复杂的从大型表中选择的实验中所实现的那样，它从本质上获得了一个目标表
类型数据
，这允许不同的目标表结构。值得一提的是，处理成本（额外，在选择之后）在那个实验中，温度相当高。
lo_struct ?= cl_abap_structdescr=>describe_by_data( header ).
ct_components = lo_struct->get_components( ).
"Loop through ct_components appending names to lv_select_clause

lv_select_clause = get_header_fields( is_target_structure = header ).
select single (lv_select_clause)
  from rbkp
  where gjahr = @iv_gjahr
    and belnr = @iv_belnr
  into corresponding fields of @header.