выборка с двух таблиц с сумированием

ufo

Ребят, хэлп. я честно скажу в сапе нуб пока и копаюсь всего третью неделю. поэтому прошу отнестись к моему вопросу снисходительно.

нужно сделать выборку с двух таблиц и проссумировать во второй таблице компоненты... если бы это был привычный мне mysql то запрос выглядил бы так:

Цитата:

select mast.matnr, mast.werks, stpo.idnrk, sum(stpo.menge)
from mast, stpo
where mast.stlnr = stpo.stlnr
group by mast.matnr;

однако, что я только не делал на abape, у меня не хватает толи мозга толи ещё чего шобы познать истину. <я не знать русский языка> уже и отдельно считать сумму во второй таблице:

Цитата:

data:
komp like stpo-idnrk,
spec_s like stpo-stlnr,
sum_menge like stpo-menge.

select idnrk, stlnr, sum (menge) as sum_menge from stpo into (komp, spec_s).
write: / komp, spec_s, sum_menge.
endselect.

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

PыSы> форум до того как создать тему читал (искал)... нашол кое-что, ничего не получилось...

Alex80

Code:

DATA:
komp LIKE stpo-idnrk,
spec_s LIKE stpo-stlnr,
sum_menge LIKE stpo-menge.

SELECT idnrk stlnr SUM( menge ) AS sum_menge
  FROM stpo INTO (komp, spec_s, sum_menge) GROUP BY idnrk stlnr.
  WRITE: / komp, spec_s, sum_menge.
ENDSELECT.

Ну хотя бы так, но это очередной пример из области "Как не нужно писать Select".

ROKO

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

Ребят, хэлп. я честно скажу в сапе нуб пока и копаюсь всего третью неделю. поэтому прошу отнестись к моему вопросу снисходительно.

нужно сделать выборку с двух таблиц и проссумировать во второй таблице компоненты... если бы это был привычный мне mysql то запрос выглядил бы так:

Цитата:

select mast.matnr, mast.werks, stpo.idnrk, sum(stpo.menge)
from mast, stpo
where mast.stlnr = stpo.stlnr
group by mast.matnr;

однако, что я только не делал на abape, у меня не хватает толи мозга толи ещё чего шобы познать истину. <я не знать русский языка> уже и отдельно считать сумму во второй таблице:

Цитата:

data:
komp like stpo-idnrk,
spec_s like stpo-stlnr,
sum_menge like stpo-menge.

select idnrk, stlnr, sum (menge) as sum_menge from stpo into (komp, spec_s).
write: / komp, spec_s, sum_menge.
endselect.

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

PыSы> форум до того как создать тему читал (искал)... нашол кое-что, ничего не получилось...

Я бы к примеру сделал вот так быб:

Code:

select mast~matnr mast~werks stpo~idnrk stpo~menge

into table itab_new from mast 

inner join stpo on 

mast~matnr = stpo~matnr.

LOOP At itab_new.

ADD itab_new TO sum_menge.

ENDLOOP.

ufo

спасибо)

а ещё один глупый вопрос не в тему...

можно ли всётаки с помощью одного селекта сделать выборку с двух таблиц или же это всётаки это бред?

ROKO

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

спасибо)

а ещё один глупый вопрос не в тему...

можно ли всётаки с помощью одного селекта сделать выборку с двух таблиц или же это всётаки это бред?

А это че

?:

ROKO написал:

Я бы к примеру сделал вот так быб:
Код:

select mast~matnr mast~werks stpo~idnrk stpo~menge

into table itab_new from mast

inner join stpo on

mast~matnr = stpo~matnr.

LOOP At itab_new.

ADD itab_new TO sum_menge.

ENDLOOP.

ufo

2 ROKO:

поправка в код:

Code:

select mast~matnr mast~werks stpo~idnrk stpo~menge

into table itab_new from mast

inner join stpo on

mast~stlnr = stpo~stlnr.

LOOP At itab_new.

ADD itab_new TO sum_menge.

ENDLOOP.

к тому же он ругаецо на строку:

Code:

ADD itab_new TO sum_menge.

вот такими матюками:

Code:

Arrifmetik operations are only intended for operands that can be converted to numbers (numeric operand)

но эту проблему уже где то встречал на форуме ща попробую сам исправить)

ишё раз спасибо всем)

P.S.>

ROKO написал:

А это че Very Happy ?:

инет жутко тормозит, поэтому скорость обновления постов маненькая) не успеваю

ROKO

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

2 ROKO:

поправка в код:

Code:

select mast~matnr mast~werks stpo~idnrk stpo~menge

into table itab_new from mast

inner join stpo on

mast~stlnr = stpo~stlnr.

LOOP At itab_new.

ADD itab_new TO sum_menge.

ENDLOOP.

к тому же он ругаецо на строку:

Code:

ADD itab_new TO sum_menge.

вот такими матюками:

Code:

Arrifmetik operations are only intended for operands that can be converted to numbers (numeric operand)

но эту проблему уже где то встречал на форуме ща попробую сам исправить)

ишё раз спасибо всем)

P.S.>

ROKO написал:

А это че Very Happy ?:

инет жутко тормозит, поэтому скорость обновления постов маненькая) не успеваю

Вставьте тупо вот такой код и проанализируйте результат

:

Code:

REPORT ufo.


DATA:  BEGIN OF wa_new OCCURS 0,
       matnr LIKE mara-matnr,
       werks LIKE mast-werks,
       idnrk LIKE stpo-idnrk,
       menge LIKE stpo-menge,
       END OF wa_new,
      it_new LIKE STANDARD TABLE OF wa_new.
DATA: sum_menge LIKE wa_new-menge.

SELECT mast~matnr mast~werks stpo~idnrk stpo~menge

INTO TABLE it_new FROM mast

INNER JOIN stpo ON

mast~stlnr = stpo~stlnr.

LOOP AT it_new INTO wa_new.

  ADD wa_new-menge TO sum_menge.

ENDLOOP.

BREAK-POINT.

---------------------------------------------------
ABAP -это вам не это, а именно то самое

Пономарев Артем

Агрегаты прекрасно работают в сочетании с джойнами.
Единственное но: в group by должны быть перечислены все поля, извлекаемые запросом.
Пример (получение сумм частичной оплаты FI проводок для кастомеров на заданную дату):

Code:

  SELECT bd1~belnr AS doc_num bd1~gjahr
         SUM( ba~wrbtr ) AS pay_pos
          INTO CORRESPONDING FIELDS OF TABLE gt_open_d_ext
          FROM bsid AS bd1
          JOIN bsid AS bd2 ON bd1~bukrs = bd2~bukrs AND
                              bd1~kunnr = bd2~kunnr AND
                              bd1~belnr = bd2~rebzg AND
                              bd1~buzei = bd2~rebzz AND
                              bd1~gjahr = bd2~rebzj
          JOIN bsad AS ba ON ba~bukrs = bd2~bukrs AND
                             ba~kunnr = bd2~kunnr AND
                             ba~augbl = bd2~belnr AND
                             ba~augdt = bd2~budat
         WHERE bd1~kunnr EQ <g_init>-client AND
               bd1~bukrs EQ <g_init>-bukrs AND
               bd1~budat LE rbudat AND
               bd1~bschl IN r_bschl_d AND
               bd1~bstat NE c_noted AND
               bd2~budat LE rbudat AND
               bd2~bstat NE c_noted AND
               ba~bschl  IN r_bschl_p AND
               ba~budat  LE rbudat AND
               ba~bstat  NE c_noted
      GROUP by bd1~belnr bd1~gjahr
      ORDER BY bd1~belnr bd1~gjahr.

vga

Пономарев Артем написал:

GROUP by bd1~belnr bd1~gjahr
ORDER BY bd1~belnr bd1~gjahr.[/code]

Думаешь сервер бд тебе спасибо скажет? :lol:

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

Пономарев Артем

Сервер БД подобный запрос просто не заметит. В моем случае тайминг не превышал 150 мс.
Первичный ключ - это еще не "наше все". Рекомендую посмотреть другие индексы перечисленных таблиц или прогнать запрос через трэйс.

vga

Пономарев Артем написал:

Сервер БД подобный запрос просто не заметит. В моем случае тайминг не превышал 150 мс.
Первичный ключ - это еще не "наше все". Рекомендую посмотреть другие индексы перечисленных таблиц или прогнать запрос через трэйс.

Это частный случай, что итоговая выборка небольшая и на сортировку на сервере затрачено мало времени. А по жизни серверу надо создавать дополнительные темповые таблицы, чтобы ко всему прочему еще и отсортировать выборку.
С суммированием я еще погу понять, это сокращает объем переданных по сети данных между серевером приложений и базой данных, а вот грузить сортировкой сервер базы данных, вообще ИМХО смысла нет.

Индексы я посмотрел перед тем, как писать в топик, в моей системе индекса, начинающегося на такие поля нет.

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

Пономарев Артем

Ну это уже частное ИМХО. Кому что нравится. Так что спорить бесмысленно. Лично я предпочитаю максимум делать на уровне БД.

С индексами проблем в запросе нет. По крайней мере по трассировке на той системе, где запрос был написан, дело ограничивалось unique и range сканами, если мне не изменяет память.

vga

При своем вообщем ;-)

Насчет range scan.
Например, существует индекс:
key1 key2 key3 key4
Мы делаем выбоку, где в качестве условия WHERE указываем
key3 = l_key3 AND key4 = l_key4

Да, в плане выполнения запроса указывается, что этот индекс используется как range scan. Но какова его эффективность, если key1 и key2 практически не дублируются? Например key1 = belnr, key2 = gjahr.

В свое время пытался найти какое-либо подтверждение, что Oracle какими-то своими внутренними способами может эффективно использовать даже такие range scan, но не нашел тому подтверждения. Пользы от такого индекса для данного запроса практически никакой.
Поэтому, если вы видите, что используется range scan - это еще ни о чем не говорит, ИМХО.
Хотелось бы услышать другое агрументированное мнение.

Пономарев Артем

Ага

Что касается range scan'a:
1. Если мы возвращаем запросом только те поля, которые входят в индекс - польза от любого доступа по индексу несомненна. Т.к. Orcale не обращается к таблице БД, а берет данные из самого индекса.
2. В любом случае range scan сокращает кол-во I/O операций. Что уже существенно повышает скорость выполнения запроса. (Я не рассматриваю вырожденные случаи).
3. В вашем примере оптимизатор, вероятно, предпочтет full index scan.

UPD: В принципе из эффективности выходит только сокращение операций чтения с дисковой подсистемы. Но это уже большой плюс. Т.к. медленнооооо...

В случае вырожденных случаев (пр.: переданные значения для where покрывают все записи в бд) получим какой-то эффект только в случае п. 1.

ufo

вот уж не подумал бы что до такого дойдёт)

в итоге оказалось всё банальней :

Code:

REPORT  Z_QTEST.

data:
       material like mast-matnr,
       zavod like mast-werks,
       komp like stpo-idnrk,
       sum_menge_a like stpo-menge.

SELECT mast~matnr mast~werks stpo~idnrk SUM( stpo~menge ) AS sum_menge_a
  INTO (material, zavod, komp, sum_menge_a) FROM mast
    INNER JOIN stpo ON
      mast~stlnr = stpo~stlnr
      GROUP BY mast~matnr mast~werks stpo~idnrk.
      write: / material, zavod, komp, sum_menge_a.
ENDSELECT.

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

выборка с двух таблиц с сумированием

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