Имеются в наличии пользовательские Z-таблицы (около 50 штук),
которые имеют следующую структуру:

Ключ (1-3 поля: BUKRS, VKORG, BWART, и т.д. )
Параметр (char40)

Вопрос следующий, как лучше сделать:

1. Оставить всё как есть, и использовать SELECT для чтения таблиц

2. Для каждой таблицы сделать FM или Class: ZCL_TABLNAME

3. Сделать один FM/Class для всех 50 таблиц, где имя таблицы и ключ будет задаваться в параметрах, и SELECT для каждой из таблиц будет генерироваться динамически

4. Вместо 50 таблиц сделать одну, и один fm/class соответственно


Я склоняюсь к варианту номер 2 по следующим причинам:
1.) Возможность отследить где в коде используется та или иная таблица через "where used"
(что невозможно вариантах в 3 или 4)

2.) Буферизация данных

Минус варианта это то, что для 50 таблиц должно быть создано 50 fm/class. Придётся писать генератор.

Сделать 1 ФМ в который передавать все параметры, а внутри селект:

select (from_clause)
from (table)
INTO TABLE (name_tab)
where (where_clause).

Встречный вопрос: а зачем нужны 50 таблиц? Нельзя их количество уменьшить?
Вам нужны выборки именно в виде таблиц 1:1 или какие-то агрегированные выборки по нескольким таблицам?
Нельзя ли использовать VIEW и меньшее количество функций/классов? Может стоит глянуть в сторону persistence objects.

Что касается буферизации - почему не загонять в буфер сами таблицы, тогда и обычные селекты быстро бегать будут...

50 таблиц - это пользовательские "Customizing Tables", с помощью которых можно включать или отключать ту или иную порцию кода в User-Exits. Количество можно уменьшить, как я уже говорил, вплоть до одной единственной таблицы. Агрегированных выборок не делается.

Например:

VIEW здесь не поможет, так как выбор скорее или между 50 разными таблицами/объектами, или между 1 единственной.

50 таблиц:
Key (Ключ1, Ключ2, Ключ3)
Параметр
Активирован-Деактивирован

ZUSEREXIT01

SELECT active INTO lv_active
FROM ZTABLE050
WHERE key1 = param1
AND key2 = param2
AND key3 = param3
AND param = param4.

IF lv_active = 'X'.
* Execute our code here
ENDIF.


1 большая таблица
Key ( Название оригинальной таблицы, Ключ1, Ключ2, Ключ3)
Параметр
Активирован-Деактивирован

ZUSEREXIT01

SELECT active INTO lv_active
FROM ZTABLE_ALL
WHERE tabname = 'ZTABLE050'
AND key1 = param1
AND key2 = param2
AND key3 = param3
AND param = param4.

IF lv_active = 'X'.
* Execute our code here
ENDIF.



Тут скорее вопрос даже не в технической реализации, а в архитектурной - что лучше: иметь 50 маленьких таблиц, и для каждой писать отдельный код, или одну большую со своими проблемами.

Маленькие легче поддерживать и выделять права доступа для разных пользователей. Большая таблица - универсальна, но стандартными средствами не обеспечить доступ пользователей только к части данных. К тому же, хотелось бы видеть, где именно используется тот или иной параметр с помощью "Where Used".

Тогда одна таблица с дополнительным полем в ключе (например USER_EXIT_NAME)... И одна функция/класс для выборки из таблицы.
Потом по функции/методу легко найдете все места использования... Тут есть один, но очень большой плюс, если вам потом надо будет расширить таблицу (создать еще одну), например для ведения прав доступа - то менять надо будет только обработку внутри класса. Все уже измененные места остаются нетронутыми.

Спасибо, приведенное Вами решение вполне разумно. Это скорее всего и есть самый оптимальный вариант в нашем случае, если начинать с нуля.

Но обращение к этим 50 таблицам имеется в 500 местах, и такое радикальное изменение архитектуры не примется с большой радостью, не говоря уже о переписывании.

Если мы оставим 50 таблиц, и у нас будет выбор или 50 вариантов SELECT/функций/классов, или же одна функция/класс с динамическим SELECT, на все 50 таблиц, чтобы Вы выбрали?

Я все-таки склоняюсь к 50 вариантам SELECT/функций/классов.

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

Есть опасность что при таком подходе со временем 50 таблиц превратятся в 500

останется только наколбасить к ним своё ZSPRO

Помоему перебор - столько таблиц городить ради вобщемто тривиальной задачи.

Как вариант - свести таки к одной таблице, заменив все остальные view-шками.

В том то и дело, что не сходное. И ключи совсем разные.

И да, данные разные по бизнес логике, поэтому и склоняюсь сейчас все-таки больше к последнему варианту. Конечно, оптимально было бы использовать всего одну таблицу, но как я уже говорил, это будет кардинальным изменением архитектуры.

В этом то все и дело, поэтому приходится искать новые решения.

Свой ZSPRO уже есть

Ну, это все до меня было сделано, что смогу то сделаю.

Да, спасибо, этот вариант рассматривается.

Кем-то это уже обсуждалось, если не ошибаюсь.
Был рассмотрен вариант использования The Persistence Service