заполнение внутренней таблицы из 2-х других таблиц

Alraun

подскажите, как построить запрос:
нужно заполнить внутреннюю таблицу данными из 2-х внутренних таблиц, допустим, ZBKPF (на основе BKPF) и ZBSEG (на основе BSEG). но! в одной строке итоговой таблицы, допустим, ZITOG, должны комбинироваться данные из 2-х строк ZBSEG. то есть мне нужно взять 2 строчки из ZBSEG с одинаковым значением, скажем, в поле ANLN1 (их ровно две, не больше). В результате чего в строчку таблицы ZITOG должны попасть: номер документа и номер позиции из первой строчки ZBSEG, соответствующая документу дата документа из ZBKPF, номер документа и номер позиции из 2-ой строчки ZBSEG, соответствующая 2-ому документу дата документа из ZBKPF.

slash

Alraun написал(а):

подскажите, как построить запрос:
нужно заполнить внутреннюю таблицу данными из 2-х внутренних таблиц, допустим, ZBKPF (на основе BKPF) и ZBSEG (на основе BSEG). но! в одной строке итоговой таблицы, допустим, ZITOG, должны комбинироваться данные из 2-х строк ZBSEG. то есть мне нужно взять 2 строчки из ZBSEG с одинаковым значением, скажем, в поле ANLN1 (их ровно две, не больше). В результате чего в строчку таблицы ZITOG должны попасть: номер документа и номер позиции из первой строчки ZBSEG, соответствующая документу дата документа из ZBKPF, номер документа и номер позиции из 2-ой строчки ZBSEG, соответствующ
ая 2-ому документу дата документа из ZBKPF.

LOOP AT zbkpf
LOOP AT zbseg WHERe ..
APPEND ...
ENDLOOP.
ENDLOOP.

T

Иногда в таких случаях можно использовать join таблицы к самой себе

Code:

select t1~f1 t1~f2 
       t2~f1 t2~f2
  into ...
  from some_table as t1
  join some_table as t2
    on t1~f3 = t2~f3
 where ...

Max Popenker

slash написал(а):

LOOP AT zbkpf
LOOP AT zbseg WHERe ..
APPEND ...
ENDLOOP.
ENDLOOP.

Мнэээ. учитывая соотношение BSEG:BKPF как много:1, не проще ли будет сперва сделать

Code:

SORT zbseg BY belnr.
SORT zbkpf BY belnr.

LOOP AT zbseg.
  AT NEW belnr.
    READ TABLE zbkpf WITH KEY belnr = zbseg-belnr BINARY SEARCH.
  ENDAT.
  MOVE-CORRESPONDING zbseg TO zitog.
  MOVE-CORRESPONDING zbkpf TO zitog.
ENDLOOP.

PS не люблю nested loops

[/code]

Дмитрий

T написал:

Иногда в таких случаях можно использовать join таблицы к самой себе

Code:

select t1~f1 t1~f2 
       t2~f1 t2~f2
  into ...
  from some_table as t1
  join some_table as t2
    on t1~f3 = t2~f3
 where ...

Это, конечно, хорошо, но bseg - кластерная таблица. JOIN по ней не пройдет.

T

Дмитрий написал:

Это, конечно, хорошо, но bseg - кластерная таблица. JOIN по ней не пройдет.

Речь шла о некой ZBSEG

ЗЫ блин, ZBSEG же внутренняя..

Дмитрий

Max Popenker написал(а):

Мнэээ. учитывая соотношение BSEG:BKPF как много:1, не проще ли будет сперва сделать

Code:

SORT zbseg BY belnr.
SORT zbkpf BY belnr.

LOOP AT zbseg.
  AT NEW belnr.
    READ TABLE zbkpf WITH KEY belnr = zbseg-belnr BINARY SEARCH.
  ENDAT.
  MOVE-CORRESPONDING zbseg TO zitog.
  MOVE-CORRESPONDING zbkpf TO zitog.
ENDLOOP.

PS не люблю nested loops

[/code]

Во-первых, задача стояла в заполнении каждой строчки zitog данными из заголовка - zbkpf и 2-х позиций - zbseg, поэтому просто циклом по zbseg'у без изменения заполненной строки итогов при проходе по второй позиции для приведенного здесь алгоритма не обойтись. А это дурная практика.

Во-вторых, у таблиц bkpf, bseg составной первичный ключ. Поэтому поиск заголовка документа только по его номеру может привести к неприятным коллизиям - для разных БЕ, года номер док-та может быть одним и тем же.
Ну и соответственно at new belnr тоже маловато, если, конечно, в определении внутренней таблицы zbkpf поля bukrs и gjahr не объявлены ранее belnr.
Вот, в общем-то, и все.

Дмитрий

T написал:

Дмитрий написал:

Это, конечно, хорошо, но bseg - кластерная таблица. JOIN по ней не пройдет.

Речь шла о некой ZBSEG

ЗЫ блин, ZBSEG же внутренняя..

ты предлагал сделать join для внутренних таблиц?

T

Дмитрий написал:

T написал:

Дмитрий написал:

Это, конечно, хорошо, но bseg - кластерная таблица. JOIN по ней не пройдет.

Речь шла о некой ZBSEG

ЗЫ блин, ZBSEG же внутренняя..

ты предлагал сделать join для внутренних таблиц?

Щаз..
я считал, что речь идет о прозрачной таблице ZBSEG, об этом я и написал, а потом допёр, что речь о внутренней, о чём дописал позже в виде PS. Прояснилось?

Alraun

Дмитрий написал:

Во-первых, задача стояла в заполнении каждой строчки zitog данными из заголовка - zbkpf и 2-х позиций - zbseg, поэтому просто циклом по zbseg'у без изменения заполненной строки итогов при проходе по второй позиции для приведенного здесь алгоритма не обойтись. А это дурная практика.

мне тоже так показалось. а как же быть? :roll:

Дмитрий

В твоем случае надо отсортировать zbseg по полю anln1,
а zbkpf по bukrs, belnr, gjahr. А лучше их объявить как сортированные таблицы.
Потом делаешь цикл по zbseg. Для "первой" строчки zbseg читаешь
заголовок
read table zbukrs with key bukrs = zbseg-buks belnr = zbseg-belnr gjahr = zbseg-gjahr binary search
и заполняешь свои поля в zitog для 1-строчки.
Для "второй" строчки также читаешь заголовок и заполняешь поля zitog для 2-й строчки и не забываешь append zitog сделать.
В двух словах вот так. Можно написать более прозрачный алгоритм, но это надо zbseg и zbkpf специальным образом определять.

Alraun

спасибо.

RoadRunner

В SE38 есть хорошая вещь - примеры производительности. Не помню, кто это мне подсказал, но там есть алгоритмы оптимизации поиска в двух связанных таблицах. Лучше будет сделать примерно так:

Code:

data: begin of zbkpf occurs 0,
        [ключ. поля],
        ...,
      end of zbkpf,

      begin of zbseg occurs 0,
        [ключ. поля],
        [доп. ключ. поле для zbseg - позиция],
       ....,
      end of zbseg.
data: ind type i.
......................
  SORT: zbkpf BY [ключ zbkpf'a],
        zbseg BY [ключ zbseg'a].
  ind = 0.
  CLEAR: zbkpf, zbseg.
  LOOP AT zbseg.
    IF zbseg-[ключ] NE zbkpf-[ключ].
      ind = ind + 1.
      READ TABLE zbkpf INDEX ind.
      ....
      MODIFY zbkpf INDEX ind.
    ELSE.
      ....
      MODIFY zbkpf INDEX ind.
    EDNIF.
  ENDLOOP.

Дмитрий

RoadRunner написал:

В SE38 есть хорошая вещь - примеры производительности. Не помню, кто это мне подсказал, но там есть алгоритмы оптимизации поиска в двух связанных таблицах. Лучше будет сделать примерно так:

У нас zbseg отсортирован по полю anln1, а zbkpf по первичному ключу таблицы bseg, но только без манданта. Так что метод параллельных курсоров никак не прокатит. Тут, в принципе, оптимизировать особо нечего - нет вложенных циклов.
Ну, от сортировки zbkpf можно избавиться, если в селект дописать order by primary key. А так - быстродействие по максимуму.

RoadRunner

Дмитрий написал:

У нас zbseg отсортирован по полю anln1, а zbkpf по первичному ключу таблицы bseg, но только без манданта. Так что метод параллельных курсоров никак не прокатит.

Что мешает отсортировать по первичному ключу? Кроме БОЛЬШОГО размера внутренней таблицы, по-моему, нет причин не делать доп. сортировку...
Кроме того, я не знаю вашей специфики - "в твоем случае лучше..." (с) Дмитрий

З.Ы. Про параллельный курсор я сказал потому, что некто предлагал делать вложенный цикл с WHERE-условием. ИМХО, безобразие

Да и в цикле делать READ TABLE ... BINARY SEARCH не лучший вариант. Если есть возможность, лучше сразу отсортировать ZBSEG по ключу, сделать необх. махинации с ZBKPF и затем отсортировать так, как вам надо.

Правила форума

заполнение внутренней таблицы из 2-х других таблиц

Кто сейчас на конференции