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 будет потрачена впустую—т.е. на обработку неоптимально сгенерированных запросов.
Если автор прав, то причина опустения ФИДО (он всё-таки жив) та же, что и Usenet—наплыв ламеров благодаря низкому порогу входа.
SQL-запрос в примере неграмотный. Он будет очень медленно работать из-за избыточной группировки по огромному числу полей. Например, если строки группируются по складу, до достаточно группировки по коду склада, а название склада можно присоединить к уже сгруппированным данным. То же относится и ко всем полям заголовочной части: раз в выборке присутствуют Бизенс-партнёр и номер документа, то значит одна строка отчёта относится строго к одному документу, а следовательно группировка по любым полям, относящимся к документу в целом, тоже безсмысленна. Поправьте меня, если я ошибаюсь.
Если я правильно понимаю, то
APInvoiceDetailQuery—это не таблица, а ракурс. Если HANA отбирает их него данные отдельнымым этапом (как из обычного подзапроса), тогда это ещё пуще затормозит процесс, потому что HANA будет сканировать все данные, независимо от фильтров и условий, добавленных в сам запрос.Чтобы избежать безсмысленной группировки, необходимо сначала вычислить только группируемые данные, а затем присоединить к ним остальные поля по ключу, например:
В таком случае:
Без этого вся мощь HANA будет потрачена впустую—т.е. на обработку неоптимально сгенерированных запросов.