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