Когда использовать внутренние таблицы?

Question

Итак, я прочитал, что использование внутренних таблиц увеличивает производительность программы и что мы должны делать операции с таблицами БД как можно меньше. Но я начал работать над проектом, который вообще не использует внутренние таблицы. Некоторые детали: Это сканер, который добавляет или удаляет продукты в/из магазина. Сначала проверяется первичный ключ (чтобы узнать, существует ли этот тип продукта), а затем добавляется или удаляется продукт. Мы используем «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. 

Но когда я могу выполнить это обновление? Я могу установить кнопку «Сохранить», чтобы выполнить обновление, но тогда возникнет риск того, что пользователь забудет сохранить большие объемы данных или сбросит сканер, отключит его или аналогичные ситуации. Так что это явно нехорошее решение. Мой последний вопрос: есть ли (хороший) способ реализовать внутренние таблицы в таком проекте?

Answer 1

Внутренние таблицы должны использоваться для обработки данных, таких как списки или массивы на других языках (C#, java ...). С точки зрения производительности и системной нагрузки предпочтительно сначала загружать все данные, которые вам нужны, во внутреннюю таблицу, а затем обрабатывать эту внутреннюю таблицу вместо загрузки отдельных записей из базы данных.

Но это в основном верно для отчетов, что, вероятно, является наиболее распространенным типом пользовательской программы abap. Вы часто видите, что разработчики используют select ... endselect-statements, которые по сути делают цикл над таблицей базы данных, передавая строку за строкой в ​​отчет по одному за раз. Это очень медленно по сравнению с чтением всех записей сразу в itab, а затем перебирает itab. Не раз я сокращал время выполнения отчета до доли, просто устраняя обратные вызовы в базу данных.

Если у вас есть повод для немедленного чтения из базы данных или записей об обновлении, вы должны сделать это. Если вы можете безопасно откладывать обновления и удалять их до момента, когда вы можете обрабатывать их все вместе, не рискуя несогласованностями, я бы подумал об улучшении. Но если есть хорошая причина (например, согласованность или потеря данных) для немедленного обновления, сделайте это.

Обновление: как указано в @vwegert относительно оператора select-endselect, оператор фактически не создает отдельные запросы к базе данных для каждой строки. Интерфейс базы данных сервера приложений оптимизирует запрос, перенося строки навалом на сервер приложений. Оттуда записи переносятся в отчет abap один за другим (потому что в отчете есть только рабочая область для хранения одной строки), которая имеет значительное влияние на производительность, особенно для запросов с большими наборами результатов. Выбор во внутренней таблице может переносить все строки непосредственно в отчет abap (пока есть достаточно памяти для их хранения), так как теперь есть внутренняя таблица для хранения этих записей в отчете.