Pull to refresh
0
0
Send message

Если автор прав, то причина опустения ФИДО (он всё-таки жив) та же, что и Usenet—наплыв ламеров благодаря низкому порогу входа.

На Си:
void printntoz( unsigned int n )
{
   Repeat: 
      printf("%u ", n);
      n--;
      switch( n >> sizeof(int) * 8 - 1 )
      {  case 0: goto Repeat;
         case 1: goto End;
      }
   End:{}
}
Спасибо за ответ. Прошу прощения за опечатки и ошибки в примере. Не могу отредактировать собственный комментарий.

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"

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


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

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

Information

Rating
Does not participate
Registered
Activity