Блог

Главная - Вопросы по программированию - SAP HANA SQL | Подсчет различных прогнозируемых значений в одном столбце

SAP HANA SQL | Подсчет различных прогнозируемых значений в одном столбце

#sql #count #hana

Вопрос:

У меня есть следующий запрос в SAP HANA. Я спроектировал столбец, который отображает результаты 02 в миллионах строк. Я хотел бы подсчитать, сколько из этих двух результатов имеет каждый ОТДЕЛЬНЫЙ ZCGNOTAL.

Пожалуйста, помогите мне.

 SELECT ZCGINSTAL, 
       ZCGNOTAL, 
       "Latitude",
       CASE WHEN "Latitude" > '0' THEN 'ZERADA' ELSE 'COORDENADA' END AS COORD
FROM "CLB162585"."062021MOM"

Ответ №1:

Насколько я понимаю вопрос, ОП хочет знать для каждого значения ZCGNOTAL , сколько записей имеют значение «ZERADA» и сколько имеют значение «COORDENADA» в вычисляемом столбце COORD .

Это может быть вычислено с помощью простого многоколоночного GROUP BY и COUNT агрегированного «сверху» существующего запроса:

 WITH base_data as (
   SELECT   ZCGINSTAL
          , ZCGNOTAL 
          , "Latitude"
          , CASE 
              WHEN "Latitude" > '0' THEN 'ZERADA' 
              ELSE 'COORDENADA' 
            END AS     COORD
FROM 
     "CLB162585"."062021MOM")
SELECT
     ZCGNOTAL
   , COORD
   , COUNT(*) as COORD_CNT 
FROM 
   base_data
GROUP BY
     ZCGNOTAL
   , COORD

При желании запрос можно переписать, чтобы не использовать выражение общей таблицы (С ПРЕДЛОЖЕНИЕМ) или подзапрос, но для SAP HANA это вряд ли приведет к повышению производительности. ХАНА все равно переписывает запрос перед оптимизацией, и разрешение подзапросов является частью этого процесса перезаписи.

Комментарии:

1. Как вы думаете, почему конкретно в HANA не будет лучше объединить два отфильтрованных набора данных с константой COORD вместо GROUP BY вычисляемого столбца? В расчетных представлениях это показывает лучшую производительность в целом, но в чистом SQL это иногда работает по-другому

2. Без данных и отслеживания фактического выполнения запросов любое обсуждение производительности-это просто предположение. Поскольку представления вычислений преобразуются в ту же структуру запросов, что и операторы SQL, базовое предположение состоит в том, что нет принципиальных различий в скорости выполнения двух одинаковых запросов.

3. Еще раз здравствуйте, спасибо! Это сработало! Я новичок в SQL и пытаюсь понять, почему это сработало. Логически вы назвали мой исходный запрос чем-то (1), затем вы просто назвали три столбца (ZCGNOTAL, COORD и посчитали все с помощью * (2). Поскольку вы просто назвали COORD, а не его два разных результата, разве он не должен учитывать все, а не отдельные результаты?

4. Рад расширить ответ; но давайте договоримся: вы предоставляете некоторые тестовые данные для своего вопроса и желаемый результат. Затем я беру те же самые тестовые данные, чтобы объяснить, как работает решение. Кроме этого, в Интернете есть множество учебных пособий по SQL. 😉

Метки: