SELECT SINGLE vs SELECT UP TO 1 ROWS ENDSELECT правильность в HANA?

Мы переходим на HANA, и сторонняя компания занимается исправлением нашего кода. Часть из них автоматизирована. Я вижу, где было сделано это изменение кода:

*{   REPLACE        DEVK9A1ZZH
*  SELECT SINGLE maktx
*                INTO tab-maktx
*                FROM makt
*                WHERE matnr EQ strmatnr
*                AND   spras EQ sy-langu.
  SELECT maktx
    UP TO 1 ROWS
    INTO tab-maktx
    FROM makt
    WHERE matnr = strmatnr
    AND   spras = sy-langu ORDER BY maktx.
  ENDSELECT.

Я думал, что SELECT SINGLE всегда предпочтительнее SELECT...UP TO 1 ROWS...ENDSELECT. и что ORDER BY ничего не делает, когда получается только одна запись. Кажется, они заменяют все SELECT SINGLE в нашем коде. Что в исходном коде моего коллеги несовместимо с HANA?


hana abap opensql
person gkubed    schedule 23.05.2018    source источник
comment
Не уверен в разнице между ключевыми словами SINGLE и UP TO, но ORDER BY говорит, что если у вас есть более одной записи, возвращаемой этим предложением WHERE, то упорядочите по этому одному полю и возьмите 1 верхнюю запись, я бы сказал, что это ОЧЕНЬ важно для SINGLE или UP TO, если только вы не уверены, что возвращается только одна запись, прежде чем UP TO/SINGLE будет применена к набору записей. В противном случае вы просто возьмете случайное maktx из промежуточного результата (до применения UP TO).   -  person JNevill    schedule 23.05.2018
comment
@JNevil, MATNR и SPRAS являются ключевыми полями MAKT, поэтому всегда возвращается одна строка. В более общем плане ORDER BY может быть полезен или бесполезен в зависимости от потребностей вашего бизнеса. Довольно часто подходит любое значение, например, при проверке существования.   -  person András    schedule 23.05.2018
comment
@JNevil, вы очень хорошо заметили, что UP TO...ORDER BY гарантирует получение первой maktx записи. Я согласен с @András, что это действительно не должно иметь значения, в данном конкретном случае, поскольку выбор уже выполнен с использованием всех ключевых полей.   -  person gkubed    schedule 23.05.2018
comment
@ Андрас, я полностью согласен. Поскольку мы выбираем по ключу, ORDER BY является излишним, более того, это SINGLE/UP TO, но, вероятно, он необходим компилятору, чтобы гарантировать, что возвращается только скалярный результат. Я не пишу достаточно abap, чтобы знать, что это было бы невозможно, если бы это было опущено. Я просто говорю из контекста РСУБД, где SINGLE/UP TO и ORDER BY присутствуют, потому что: лучше перестраховаться, чем потом сожалеть и проверить будущее для следующего динь-донга, который появляется и изменяет условие WHERE, чтобы не выбирать ключи.   -  person JNevill    schedule 23.05.2018

Ответы (3)


arrow_upward
1
arrow_downward

Городская легенда (и мой опыт, но я не могу это доказать) гласит, что обычные СУБД предоставляют строки с использованием первичного ключа только потому, что именно так они хранят данные. HANA сортирует по столбцам, а не по строкам, поэтому, когда вы запрашиваете только одну строку, она возвращает вам первую строку, которую «она» может построить с вашими условиями.

Поскольку вы не можете сделать SELECT SINGLE...ORDER BY, вы должны найти альтернативный способ:

  • рекомендуется: выполнить предложение WHERE с достаточным количеством условий, чтобы получить строку, которая вам действительно нужна
  • попросите HANA имитировать поведение старой СУБД, запросив «только одну строку, ища по первичному ключу»

Если вам удается всегда предоставлять предложение WHERE с достаточным количеством условий, вы можете продолжать с синтаксисом SINGLE, но я боюсь, что некоторые компании попросят вас НЕ делать этого, потому что они столкнулись с результатами ленивых кодеров, которые полагались на старое поведение СУБД: (

person VXLozano    schedule 23.05.2018
comment
Обычные СУБД предоставляют строки с использованием первичного ключа просто потому, что именно так они хранят данные. HANA сортирует по столбцам, а не по строкам, поэтому, когда вы запрашиваете только одну строку, она возвращает вам первую строку, которую она может построить с вашими условиями. Все это утверждение просто не соответствует действительности. Возврат данных через первичный ключ кажется одной из городских легенд баз данных... - person Lars Br.; 24.05.2018
comment
Добавлено вступление с городской легендой, так как я не могу подтвердить свое предположение фактами. Просто СУБД всегда давала мне данные :( - person VXLozano; 24.05.2018

arrow_upward
1
arrow_downward

Иногда нужно, чаще нет

В основном это не нужно, как и в вашем примере.

SELECT SINGLEs можно разделить на 3 группы:

  • Полный поиск по первичному ключу
  • Проверка существования
  • Другой

Полный поиск по первичному ключу

matnr и spras являются первичными ключевыми полями таблицы makt, поэтому одна и та же строка уже возвращается, независимо от какого-либо порядка.
Я полагаю, что сторонний инструмент недостаточно сложен для проверки ключевых полей выбранной таблицы.

Проверка существования

Довольно много SELECT SINGLE используются только для проверки наличия значений в БД.

SELECT SINGLE posnr
    FROM VBPA 
    WHERE vbeln = iv_vbeln

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

Когда это полезно?

Только в третьем случае, когда у нас нет полного первичного ключа, но мы все равно заботимся о порядке. Это довольно редко.

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

Этот инструмент даст вам больше ложных срабатываний, чем полезных выводов.

person András    schedule 23.05.2018
comment
Понял, это почти то, что мы определили. Эта форма массового изменения действительно полезна только для исправления случаев, когда порядок СУБД по строке зависел, но теперь не зависит (поскольку он сортируется по столбцам). Кажется, что поле, которое они выбирают для сортировки, является произвольным (в моем примере это не ключевое поле, а то, что было выбрано). Спасибо! - person gkubed; 23.05.2018

arrow_upward
1
arrow_downward

Ваш код хорош в любом случае (но гораздо более эффективно закодирован в первой, неисправленной версии), потому что вы выдаете первичный ключ MAKTX (MATNR + SPRAS), и, таким образом, может быть возвращена только одна запись, а порядок не имеет значения.

Автоматические исправления HANA обычно делают много ненужных «исправлений», но это особенно раздражает.

person TallDave    schedule 05.11.2019