Por que o SQL Server exige que o comprimento do tipo de dados seja o mesmo ao usar o UNPIVOT?

Qual é a lógica por trás de exigir o mesmo comprimento ao usar o UNPIVOT?

Esta questão só pode ser verdadeiramente respondida pelas pessoas que trabalharam na implementação do UNPIVOT. Você pode obter isso entrando em contato com eles para obter suporte . O seguinte é o meu entendimento do raciocínio, que pode não ser 100% preciso:

T-SQL contém qualquer número de instâncias de semântica estranha e outros comportamentos contra-intuitivos. Alguns deles acabarão desaparecendo como parte dos ciclos de descontinuação, mas outros podem nunca ser 'melhorados' ou 'consertados'. Além de qualquer outra coisa, existem aplicativos que dependem desses comportamentos, portanto, a compatibilidade com versões anteriores deve ser preservada.

As regras para conversões implícitas e derivação de tipo de expressão respondem por uma proporção significativa da estranheza mencionada acima. Não invejo os testadores que precisam garantir que os comportamentos estranhos (e muitas vezes não documentados) sejam preservados (sob todas as combinações de SETvalores de sessão e assim por diante) para novas versões.

Dito isso, não há um bom motivo para não fazer melhorias e evitar erros do passado ao introduzir novos recursos de linguagem (obviamente sem bagagem de compatibilidade com versões anteriores). Novos recursos como expressões de tabela comuns recursivas (como mencionado por Andriy M em um comentário) e UNPIVOTestavam livres para ter uma semântica relativamente sã e regras claramente definidas.

Haverá uma variedade de pontos de vista sobre se incluir o comprimento no tipo está levando a digitação explícita longe demais, mas pessoalmente eu a acolho. Na minha opinião, os tipos varchar(25)e nãovarchar(50) são os mesmos, não mais do que e são. A conversão especial do tipo de cadeia de revestimento complica as coisas desnecessariamente e não agrega valor real, na minha opinião.decimal(8)decimal(10)

Pode-se argumentar que apenas as conversões implícitas que podem perder dados devem ser declaradas explicitamente, mas também existem casos extremos. Em última análise, uma conversão será necessária, portanto, podemos torná-la explícita.

Se a conversão implícita de varchar(25)para varchar(50)fosse permitida, seria apenas outra conversão implícita (provavelmente oculta), com todos os casos extremos estranhos usuais e SETsensibilidades de configuração. Por que não tornar a implementação o mais simples e explícita possível? (Nada é perfeito, no entanto, e é uma pena que esconder varchar(25)e varchar(50)dentro de um sql_variantseja permitido.)

Reescrever o UNPIVOTcom APPLYe UNION ALLevita o (melhor) tipo de comportamento porque as regras para UNIONestão sujeitas à compatibilidade com versões anteriores e estão documentadas nos Manuais Online como permitindo tipos diferentes, desde que sejam comparáveis ​​usando conversão implícita (para a qual as regras misteriosas de precedência de tipo de dados são usados, e assim por diante).

A solução envolve ser explícito sobre os tipos de dados e adicionar conversões explícitas quando necessário. Isso parece um progresso para mim :)

Uma maneira de escrever a solução alternativa digitada explicitamente:

SELECT
    U.PersonId,
    U.ColumnName,
    U.Value
FROM dbo.People AS P
CROSS APPLY
(
    VALUES (CONVERT(varchar(50), Lastname))
) AS CA (Lastname)
UNPIVOT
(
    Value FOR
    ColumnName IN (P.Firstname, CA.Lastname)
) AS U;

Exemplo de CTE recursivo:

-- Fails
WITH R AS
(
    SELECT Dummy = 'A row'
    UNION ALL
    SELECT 'Another row'
    FROM R
    WHERE Dummy = 'A row'
)
SELECT Dummy
FROM R;

-- Succeeds
WITH R AS
(
    SELECT Dummy = CONVERT(varchar(11), 'A row')
    UNION ALL
    SELECT CONVERT(varchar(11), 'Another row')
    FROM R
    WHERE Dummy = 'A row'
)
SELECT Dummy
FROM R;

Por fim, observe que reescrever usando CROSS APPLYna pergunta não é exatamente o mesmo que UNPIVOT, porque não rejeita NULLatributos.

O UNPIVOToperador utiliza o INoperador. As especificações para o operador IN (captura de tela abaixo) indicam que tanto o test_expression(neste caso, à esquerda do IN) quanto cada expression(no lado direito do IN) devem ser do mesmo tipo de dados. Graças à propriedade transitiva de igualdade, cada expressão também deve ser do mesmo tipo de dados.