O SQL Server suporta MAIOR e MENOR, se não, qual é a solução comum?

Um método comum é usar a VALUEScláusula e CROSS APPLYas duas colunas com alias como uma única coluna e, em seguida, obter o MINe MAXde cada uma.

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 );

Existem outras maneiras de escrevê-lo, por exemplo, usandoUNION 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);

No entanto, os planos de consulta resultantes parecem ser os mesmos.

O SQL Server agora dá suporte a essas duas funções no Azure SQL DB e, presumivelmente, elas estarão disponíveis no local para o SQL Server 2022.

Você também pode colocar os valores embutidos em uma subconsulta. Assim:

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

GREATESTe LEASTagora têm suporte no Azure SQL e terão suporte no SQL Server 2022.

MENOS equivalente:

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

MAIOR equivalente:

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

Para sua informação, implementamos MAIOR e MENOS no Azure SQL DB e nas próximas versões do SQL Server:

https://learn.microsoft.com/en-us/sql/t-sql/functions/logical-functions-greatest-transact-sql?view=sql-server-ver15

Este seria um bom começo -

CASE WHEN A > B THEN A ELSE B END

Eu pretendia adicionar um comentário à resposta do @ed-avis, mas não consegui, devido à falta de reputação, então postei isso como extensão da resposta dele.

Eu eliminei a desvantagem de "Irritantemente você tem que fazer funções separadas para cada tipo de dados." Usando SQL_VARIANT .

Aqui está minha implementação:

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;

Além disso, esta função lida com NULL s como a versão postgresql.

Essa função pode ser adicionada ao banco de dados por conveniência, mas é 10 vezes mais lenta do que usar o IIF. Meus testes mostram que essa função com tipo exato ( datetime ) executa o mesmo que a versão sql_variant .

PS Eu executo alguns testes no conjunto de dados de 350k valores e parece que o desempenho é o mesmo, sql_variant é um pouco mais rápido, mas acredito que seja apenas jitters.

Mas de qualquer forma a versão IIF é 10x mais rápida!!!

Eu não testei inline, CASE WHENmas basicamente para t-sql IIF é o mesmo que case e iif get é convertido pelo otimizador para a expressão case.

O fato de o IIF ser traduzido em CASE também tem impacto em outros aspectos do comportamento desta função.

CONCLUSÃO: É mais rápido usar IIF se o desempenho for importante, mas para prototipagem, ou se a clareza do código for mais necessária, e não houver grandes cálculos envolvidos, desde que a função possa ser usada.

Eu crio funções definidas pelo usuário, por exemplo

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

Você também pode fazer um usando sql_variantem vez de int, que funcionará com qualquer tipo. (Infelizmente, ele sofre com as regras de conversão de tipo 'úteis' do MSSQL, retornando sem sentido se chamado com (1, 'a')em vez de um erro.) Pelo menos o desempenho com sql_variantnão parece pior do que a versão para um tipo específico.

Embora possa funcionar em casos simples, existem vários problemas com essa abordagem:

• Irritantemente você tem que fazer funções separadas para cada tipo de dados.
• Ele lida com apenas 2 parâmetros, portanto, pode-se precisar de mais funções para lidar com muitos parâmetros ou usar chamadas aninhadas das mesmas funções.
• Seria melhor (mais eficiente) como um TVF embutido em vez de uma função escalar. Isso tem a ver com a implementação de funções escalares no coração. Existem muitos blogs sobre isso, veja por exemplo SQL 101: Parallelism Inhibitors – Scalar User Defined Functions (por John Kehayias . (No entanto, as versões mais recentes do MSSQL podem otimizar melhor as funções escalares.)
• Além dos problemas com funções escalares e otimização de consulta, mesmo em uma consulta direta, uma expressão iifou escrita à mão caseé cerca de dez vezes mais rápida que a chamada de função.
• Se um dos argumentos for nulo, ele retornará nulo. Isso corresponde ao que o leastoperador faz no Oracle e no MySQL, mas difere do Postgres. Mas essa blindagem contra null o torna mais detalhado (se você sabe que eles não serão null, um simples case when @a <= @b then @a else @b endfuncionaria).

Em suma, pode ser melhor escrever a caseexpressão à mão se o desempenho for importante. Eu até recorri à geração de caseinstruções aninhadas no lado do cliente quando há vários valores para comparar.