Возможности ERP-решения SAP Business One на платформе SAP HANA / Comments / Habr

imbasoft Mar 28 2017 at 16:37

Коллеги, сори за офтоп, но не удержался. SAP HANA на мой взгляд не самая удачное название для России, у меня почему то все оно превращаться в «Хана сапу», то есть все нет больше сапа.

А в целом решение и статья интересные.

SAP Mar 28 2017 at 16:38

Спасибо за мнение, но SAP -глобальная компания, поэтому названия едины по всему миру

jusiter Mar 29 2017 at 11:55

Renault тоже глобальная компания, однако ж «CAPTUR» для россии на всякий случай назвали KAPTUR

SergeyUstinov Mar 28 2017 at 17:28

Коллеги, буквы EPR выглядят свежо и загадочно, но может исправите ошибку в названии статьи? :)))

SAP Mar 28 2017 at 17:31

Спасибо! Тест на внимательность пройден!

Ant_222 Apr 4 2017 at 09:50

SQL-запрос в примере неграмотный. Он будет очень медленно работать из-за избыточной группировки по огромному числу полей. Например, если строки группируются по складу, до достаточно группировки по коду склада, а название склада можно присоединить к уже сгруппированным данным. То же относится и ко всем полям заголовочной части: раз в выборке присутствуют Бизенс-партнёр и номер документа, то значит одна строка отчёта относится строго к одному документу, а следовательно группировка по любым полям, относящимся к документу в целом, тоже безсмысленна. Поправьте меня, если я ошибаюсь.

Если я правильно понимаю, то APInvoiceDetailQuery—это не таблица, а ракурс. Если HANA отбирает их него данные отдельнымым этапом (как из обычного подзапроса), тогда это ещё пуще затормозит процесс, потому что HANA будет сканировать все данные, независимо от фильтров и условий, добавленных в сам запрос.

Чтобы избежать безсмысленной группировки, необходимо сначала вычислить только группируемые данные, а затем присоединить к ним остальные поля по ключу, например:

SELECT
    GROUPED.*,
    -- все нужные описательные поля из INV1 и OINV
FROM
(   SELECT
        DocEntry,
        SUM("Quantity")                   AS "Quantity",
        SUM("OpenQuantity")               AS "OpenQuantity",
        SUM("TaxAmountLC")                AS "TaxAmountLC"
        SUM("LineTotalAmountLC")          AS "LineTotalAmountLC"
    FROM INV1
    WHERE <Conditions>
    GROUP BY "DocEntry"
) GROUPED
JOIN INV1 ON INV1."DocEntry" = GROUPED."DocEntry"
JOIN OINV ON OINV."DocEntry" = INV1."DocEntry"

В таком случае:

Оператор группировки будет выполнять только полезную работу.
Данные будут отфильтрованы непосредственно в момент их появления, что предотвратит сканирование лишних данных и уменьшит трафик из подзапросов наружу.

Без этого вся мощь HANA будет потрачена впустую—т.е. на обработку неоптимально сгенерированных запросов.

SAP Apr 4 2017 at 09:51

Спасибо за комментарий.
Данный запрос построен графическим редактором, поэтому могут быть технические аспекты, связанные со сложной интерпретацией графический вид-> текстовый вид запроса. Профессионал в построении запросов может использовать SQL-синтаксис для оптимизации подобных запросов или вообще без использования графического инструмента – SAP HANA Studio это позволяет. Сотрудник без знаний SQL-синтаксиса, владелец бизнеса, в штате которого нет IT-службы, может использовать графический инструмент.

Ant_222 Apr 4 2017 at 11:40

Спасибо за ответ. Прошу прощения за опечатки и ошибки в примере. Не могу отредактировать собственный комментарий.