2

所以，我读到使用内部表可以提高程序的性能，我们应该尽可能少地对 DB 表进行操作。但是我已经开始研究一个根本不使用内部表的项目。

一些细节：

它是一种在商店中添加或删除产品的扫描仪。首先检查主键（查看是否存在该类型的产品），然后添加或删除产品。我们使用“插入”和“删除自”直接从数据库表中添加/删除产品。

我没有问他们为什么不使用内部表，因为到目前为止我还没有更好的解决方案。

到目前为止，这是我所拥有的：将所有产品插入一个内部表中，将删除的产品放在另一个内部表中。

Form update.
  Modify zop_db_table from table gt_table." – to add all new products
  LOOP AT gt_deleted INTO gs_deleted.
    DELETE FROM zop_db_table WHERE index_nr = gs_deleted-index_nr.
  ENDLOOP.  " – to delete products
Endform.

但是我什么时候可以执行此更新？我可以设置一个“保存按钮”来执行更新，但这样就会有用户忘记保存大量数据、或丢弃扫描仪、将其关闭或类似情况的风险。所以这显然不是一个好的解决方案。我的最后一个问题是：在这样的项目中是否有（好的）方法来实现内部表？

4

1 回答 1

6

内部表应该用于数据处理，例如其他语言（c#、java...）中的列表或数组。从性能和系统负载的角度来看，最好先将所需的所有数据加载到内部表中，然后处理该内部表，而不是从数据库中加载单个记录。

但这对于报告来说主要是正确的，这可能是最常见的自定义 abap 程序类型。您经常看到开发人员使用 select...endselect-statements，它实际上循环遍历数据库表，将一行一行地传输到报告中，一次一个。与一次将所有记录读入 itab 然后循环遍历 itab 相比，这非常慢。我不止一次通过消除到数据库的往返来将报告的执行时间缩短到一小部分。

如果您有充分的理由立即从数据库中读取或更新记录，您应该这样做。如果您可以安全地将更新和删除延迟到可以一起处理所有更新和删除的时间点，而不会冒不一致的风险，我会考虑改进。但如果有充分的理由（如一致性或数据丢失）立即更新，那就去做吧。

更新：正如@vwegert 关于 select-endselect 语句所提到的，该语句实际上并没有为每一行创建单独的数据库查询。应用服务器的数据库接口优化查询，将行批量传输到应用服务器。从那里记录被一一传输到abap报告（因为在报告中只有工作区来存储单行），这对性能有很大的影响，尤其是对于具有大结果集的查询。选择到内部表可以将所有行直接传输到 abap 报告（只要有足够的内存来保存它们），因为现在有内部表来保存报告中的这些记录。

于 2016-01-19T07:31:00.623 回答