所以，我读到使用内部表可以提高程序的性能，我们应该尽可能少地对数据库表进行操作。但是我已经开始研究一个根本不使用内部表的项目。
一些细节：
它是在商店中添加或删除产品的扫描仪。首先检查主键（以查看是否存在该类型的产品），然后添加或删除产品。我们使用"插入到"和"删除自"直接从数据库表中添加/删除产品。
我没有问他们为什么不使用内部表，因为到目前为止我没有更好的解决方案。
这是我到目前为止所拥有的：将所有产品插入内部表中，将已删除的产品放在另一个内部表中。
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.
但是我什么时候可以执行此更新？我可以设置一个"保存按钮"来执行更新，但这样就会有用户忘记保存大量数据、丢弃扫描仪、关闭扫描仪或类似情况的风险。所以这显然不是一个好的解决方案。我的最后一个问题是：有没有一种（好的）方法可以在这样的项目中实现内部表？
内部表应该用于数据处理，就像其他语言（C#，Java...）中的列表或数组一样。从性能和系统负载的角度来看，最好先将所需的所有数据加载到内部表中，然后处理该内部表，而不是从数据库加载单个记录。
但这主要适用于报告，这可能是最常见的自定义 abap 程序类型。您经常看到开发人员使用选择...endSelect语句，实际上循环访问数据库表，一次一行地将一行一行传输到报表。与一次将所有记录读取到 itab 中，然后在 itab 上循环相比，这是非常慢的。我不止一次通过消除对数据库的往返，将报告的执行时间缩短到一小部分。
如果您有充分的理由立即从数据库中读取或更新记录，则应这样做。如果您可以安全地将更新和删除延迟到可以一起处理所有更新和删除的时间点，而不会冒不一致的风险，我会认为这是一种改进。但是，如果有充分的理由（如一致性或数据丢失）立即更新，请执行此操作。
更新：正如@vwegert提到的关于 select-endselect 语句，该语句实际上并没有为每一行创建单独的数据库查询。应用程序服务器的数据库接口优化查询，将行批量传输到应用程序服务器。从那里，记录将逐个传输到 abap 报表（因为在报表中只有用于存储单行的工作区），这对性能有重大影响，尤其是对于具有大型结果集的查询。选择到内部表中可以将所有行直接传输到 abap 报告（只要有足够的内存来保存它们），因为现在有内部表在报告中保存这些记录。