Как по скорости будет?

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

наоборот, как раз) CDS просто создана для такой фигни)

нифига

А можешь глянуть, какой он при этом запрос сообразит?

"MSEG_DIR"."ZEILE" = RTRIM( RIGHT( "VBFA_DLV"."POSNN", 4 )

? делаем ракурс из таблиц. чем ближе к базе - тем молоджнее

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

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

с фига ли? и то и то таблицы переменных данных. Оптимайзер их будет как-то различать? Да ну?

да причем тут оптимайзер?) если таблицы имеют разное назначение, зачем квадратное впихивать в треугольное?

Да брось. Особенно в хане уж так категорично об этом говорить не стоит.

Ну да, таскать туда-сюда таблицы, виртуозно вращая их в fae - это топ, конечно.

ну то есть как бы когда мы говорим про всякий dry/clean/kiss/solid/etc - то тут как бы давайте ответственность разделять. а когда ракурсы - давайте царь-ракурс (aka царь-класс)?)

почему в hana не категорично? типа все должна перемолоть?

ну выше говорили про join itab

Так itab для джойна ж не весь, а строго нужный: ключи уникальные.

Типа, концепция: база сильная, клиент слабый.

не понял? есть бизнес задача: читать данные признаков на определенную дату. Данных ausp и иже с ним мало. За неимением гербовой используем туалетную. Читаем данные из доков изменений. Оптимайзер вполне при том. Я описал как ведет себя хана при такой выборкею. И никаких год-обжект и тд, что ты ниже нафантазировал. Т.к. рекомендованный сап подход с "стройте иерархию цдс" не устроил в связи с низкой производительностью - пришлось городить большой запрос

change pointer не рассматривали? или слепили из того, что было? и кроме того, что-то не вижу в этой задаче join aups, cdhdr/cdpos. взяли объект (ausp), прочитали изменения к нему (Cdhdr/cdpos)... где большой запрос?

Связь между cdhdr/ausp по конкатенированному ключу. Вот в нем проблема была. Change pointer то каким боком? У меня уже есть данные в бд. Мне не надо пилить обработку по факту изменения

»»Вот в нем проблема была. это непроблема)) это был намек от SAP, что нефиг так делать)) »»»Change pointer то каким боком? если данные важны, то их надо было складывать отдельно и оттуда брать в нормальном виде. если надо - то через время чистить

А, ну то есть, а то что цдс работает через ж в этом случае это уже мелочь? Логично. Не подкопаешься 🤣

Как-то неубедительно выглядит требование в cdpos копаться. А если там лярды записей, бегать по партициям придётся. Ладно бы аудит какой-то, а тут просто любопытство для ausp?

Заказчик сказал "надо", консалт ответил - "есть" ... А подумать... Подумал всякое, но что именно - мы не узнаем, тк он был очень воспитанный 🤣