Кто-нибудь пробовал преобразовать BSEG в прозрачную таблицу? Какие-нибудь проблемы появлялись при этом?

В курсе BC490 есть такая строка по поводу кластерных таблиц:
"If SAP does not provide an alternative access path, you can consider removing the table from the table cluster. However, you must consult SAP (R/3 Note or support) before doing this."
Т.е., в принципе, позволительно преобразовать BSEG к нормальному виду. Зачем? Затем, чтобы появилась возможность увеличить производительность транзакций, отчетов и т.д., т.к. появляется возможность создавать вторичные индексы.
Увеличение физичекого объема таблицы не есть проблема сама по себе, т.к. это естественная плата за производительность. Но возможно есть какие-то побочные эффекты? Кто-то сталкивался с чем то подобным?

Преобразовывать никуда bseg не стоит. Причин объяснять не буду. Их много.
Посмотри таблицы bsis, bsas, bsid, bsad, bsik, bsak, bsim, bsam. Для подавляющего большинства отчетов их более чем достаточно.

И все таки: может хотя бы ссылку на них дашь?
Для отчетов таблиц вторичных индексов недостаточно, тем более что многие поля в них отличаются по содержанию от bseg.
Как пример: заполнение полей XREF1, XREF2, XREF3 и ZUONR в BSEG и к примеру в BSIK

BSEG еще ладно - действительно, с помощью вторичных индексов многое разруливается.
Вот с T030, помнится, накувыркался...

Все таки хотелось бы узнать эти причины. Одну я знаю, это значительно бОльший физический объем, т.к. большинство полей записи пустое, а кластерные таблицы такие поля компрессуют.
Какие еще?



Эти таблицы знаю и использую, но считаю это большим извратом, к тому же еще и плохо работающим (Удав прав). Они и называются то индексами, т.е. это попытка SAP создать то, чего не хватает.

Я тут собрал немного статистику заполняемости полей BSEG (~28 тыс. записей). На графике каждый столбик это поле BSEG, его длина означает количество записей, в которых оно не пустое. Отсортированы по убыванию.



Фактически, площадь серого цвета показывает неиспользуемый объем таблицы. Вероятно при преобразовании BSEG в прозрачную таблицу, ее физический объем увеличится во столько раз, во сколько видимая площадь фона больше общей площади столбиков.

Как решить эту проблему?!

Мысли:
1.
Хоть как то ее нормализовать, например разбить на несколько таблиц. Разбив даже на две части (красные прямоугольники) можно сократить объем в несколько раз. А потом, например, объединить их в один ракурс ведения с названием BSEG.
Сомнительно, что это вообще сработает. Но прежде чем набивать шишки на собственном опыте хотелось бы услышать "почему не сработает"?

2.
Оставить BSEG в кластерах, но создать свой вторичный индекс (по типу BSIS, BSAS) из наиболее цитируемых полей.
Немного покопался в спецрегистрах, слишком тяжеловесно получается. Наверно проще создать пользовательскую таблицу и через какое-то событие ее заполнять. Вопрос: какое событие можно использовать для гарантированного отслеживания изменений BSEG? Пока знаю только Open FI 1050. Может кто-то знает чего получше?

Похоже облом. SAP просто не позволяет создать редактируемый ракурс из более, чем одной, таблиц. Так называемый "ракурс ведения" вообще фикция, а не ракурс, т.е. в СУБД вообще не создается VIEW. Выходит нормализовать BSEG без изменения всех ее вызовов невозможно... Остается только 2-й вариант.

Вы не правы. SAP позволяет создать ракурс ведения по нескольким таблицам, по крайней мере в 4.7. Правда, с одним существенным ограничением.

Вот выдержка из хелпа по INSERT:
You can only insert data using a view if the view refers to a single table and has the maintenance status "No restriction" in the ABAP Dictionary.

Правда у нас версия 4.6, может в 4.7 что-то изменилось?

Касаемо "ракурса ведения" (именно в терминах САП), повторюсь, что это вообще не ракурс, т.к VIEW не создается. Т.е. конструкция типа "INSERT <имя ракурса ведения>" сругнется еще на этапе компиляции, что такого ракурса нет.

Ракурс ведения нужен для генерации диалогов ведения таблиц. Поэтому заполнить его программно не получится. Разве что сделать batch на sm30...

Вот эту мысль сейчас и думаю усиленно . Создал прозрачную табличку (ZBSEG), куда включил основную часть используемых полей (практически первый красный прямоугольник, см. картинку выше). Для добавления и модификации записей пока задействовал события Open FI:
1. 00001030 "ПРОВОДКА ДОКУМЕНТА: Обновление стандартных данных" (P/S)
Для добавления проводок, введенных вручную.

2. 00001050 "ПРОВОДКА ДОКУМЕНТА: RW-интерфейс" (P/S)
Для добавления автоматических проводок

3. 00005011 "BW: запись указателя изменений BKPF" (процесс)
Для изменений существующих проводок (вручную, выравниваний).

Не знаю, достаточно ли их для всех случаев. Проверял ручной ввод/изменение FI-документов, выравнивания (также отмену и сторнирование), вроде работает формирование из MM (кто-то проводил, сам не умею).

Может кто-то еще подскажет события, которые я не учел?

P.S.
Добавил в таблицу еще одно поле, недостающий "год выравнивания" для полного ключа к AUGBL. Теперь можно его включить в индекс и нормально оптимизировать select-ы по поиску выравниваний. Год приходится выковыривать в событиях 1030 и 5010, т.к. он вовсе не есть = AUGDT(4), как многие наивно заблуждаются.

если нужна "нормальная" копия, то легче разобраться со спец регистрами

Пожалуй еще поковыряюсь с ними тоже, но у меня создалось впечатление, что далеко не все поля из BSEG можно включить в регистры. Да и своих полей (и таблиц) лишних (для меня) они создают кучу. Если с Open FI все получится, то ни к чему эти регистры. А уж с полем "год документа выравнивания" похоже только через Open FI и получится.

а зачем тебе ВСЕ поля? Зуд унифицировать все раз и навсегда часто появляется. С этим надо бороться. Спеуиализированные решения с возможностью расширений всегда лучше громоздкого "универсального" решения

А кто сказал что я ВСЕ переношу? Наоборот (см. выше). Но если нет возможности выбрать из ВСЕХ, то это ограничение будущего расширения.

P.S.
"Унифицировать все раз и навсегда", это идеал, к которому надо стремиться! Бороться надо с нежеланием это делать. Куча специализированных решений однажды перерастает в громоздкое неуниверсальное решение, практически неуправляемое. Яркое доказательство тому R/3!