Поддерживает ли SQL Server GREATEST и LEAST, если нет, то каков общий обходной путь?

Рассматривая этот вопрос, кажется, что это большая работа, которая не должна быть необходима. Они пытаются расширить диапазон датой. В других базах данных вы просто используете greatestи least..

least(extendDate,min), greatest(extendDate,max)

Когда я пытаюсь использовать их, я получаю

'least' is not a recognized built-in function name.
'greatest' is not a recognized built-in function name.

Это будет охватывать расширение в любом направлении.

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

Мне просто интересно, как пользователи SQL Server реализуют шаблоны запросов для имитации leastи greatestфункциональности.

• PostgreSQL GREATEST/LEAST
• MySQL GREATEST/LEAST
• MariaDB GREATEST LEAST
• DB2 GREATEST LEAST
• оракул GREATEST LEAST

Развертываете ли вы условия в CASEзаявлениях или есть расширение, сторонняя надстройка или лицензия от Microsoft, которая включает эту функцию?

Один из распространенных методов - использовать VALUESпредложение, и CROSS APPLYдва столбца с псевдонимами будут представлены как один столбец, а затем получить MINи MAXкаждого.

SELECT MIN(x.CombinedDate) AS least, MAX(x.CombinedDate) AS greatest
FROM   dbo.Users AS u
CROSS APPLY ( VALUES ( u.CreationDate ), ( u.LastAccessDate )) AS x ( CombinedDate );

Есть и другие способы написания, например, используя UNION ALL

SELECT MIN(x.CombinedDate) AS least, MAX(x.CombinedDate) AS greatest
FROM   dbo.Users AS u
CROSS APPLY ( SELECT u.CreationDate UNION ALL SELECT u.LastAccessDate ) AS x(CombinedDate);

Тем не менее, итоговые планы запросов выглядят одинаково.

Вы также можете поместить значения встроенными в подзапрос. Как это:

select (select max(i) from (values (1), (2), (5), (1), (6)) AS T(i)) greatest,
       (select min(i) from (values (1), (2), (5), (1), (6)) AS T(i)) least

Это было бы хорошим началом -

CASE WHEN A > B THEN A ELSE B END

Меньше всего эквивалент:

IIF(@a < @b, @a, @b)

САМЫЙ БОЛЬШОЙ эквивалент

IIF(@a > @b, @a, @b)

Я создаю пользовательские функции, например

create function dbo.udf_LeastInt(@a int, @b int)
returns int
with schemabinding
as
begin
  return case when @a <= @b then @a 
              when @b < @a  then @b
              else null
         end
end

Хотя это может работать в простых случаях, однако есть несколько проблем с этим подходом:

• Досадно, что вы должны сделать отдельные функции для каждого типа данных.
• Он обрабатывает только 2 параметра, поэтому может потребоваться больше функций для обработки многих параметров или использования вложенных вызовов тех же функций.
• Было бы лучше (более эффективно) использовать встроенный TVF, а не скалярную функцию. Это связано с реализацией скалярных функций в глубине души. Об этом много блогов, см., Например, SQL 101: Ингибиторы параллелизма - скалярные пользовательские функции (автор Джон Кехайяс .
• Если один из аргументов равен нулю, он возвращает ноль. Это соответствует тому, что leastоператор делает в Oracle и MySQL, но отличается от Postgres. Но эта защита от нуля делает его более многословным (если вы знаете, что они не будут нулевыми, case when @a <= @b then @a else @b endсработает простая ).

В целом, может быть, лучше написать caseвыписку, если производительность имеет значение. Я даже прибегал к генерации вложенных caseоператоров на стороне клиента, когда есть несколько значений для сравнения.

Я собирался добавить комментарий к ответу @ ed-avis, но не смог этого сделать из-за отсутствия репутации, поэтому разместил это как продолжение своего ответа.

Я устранил недостаток: «Досадно, что вы должны создавать отдельные функции для каждого типа данных». Использование SQL_VARIANT .

Вот моя реализация:

CREATE OR ALTER FUNCTION my_least(@a SQL_VARIANT, @b SQL_VARIANT)
returns SQL_VARIANT
with schemabinding
as
begin
  return case when @a <= @b then @a 
              when @b < @a  then @b
              WHEN @a IS NULL THEN @b
              WHEN @b IS NULL THEN @a
              else null
         end
END;

Также эта функция обрабатывает NULL как версия postgresql.

Эту функцию можно добавить в БД для удобства, но она в 10 раз медленнее , чем встроенная IIF. Мои тесты показывают, что такая функция с точным типом ( datetime ) выполняет так же, как версия sql_variant .

PS Я запускаю несколько тестов для набора данных со значениями в 350 тыс., И кажется, что производительность одинакова, sql_variant чуть-чуть быстрее, но я считаю, что это просто дрожь.

Но в любом случае версия IIF в 10 раз быстрее !!!

Я не тестировал inline, CASE WHENно в основном для t-sql IIF такой же, как case , и iif get конвертируется оптимизатором в case case.

Тот факт, что IIF переведен на CASE, также влияет на другие аспекты поведения этой функции.

ЗАКЛЮЧЕНИЕ: быстрее использовать IIF, если производительность имеет значение, но для прототипирования или если ясность кода более необходима и не требуются большие вычисления, при условии, что можно использовать функцию.