Por que ORDER BY não pertence a uma View?

(Exibições indexadas à parte, é claro.)

Uma visão não é materializada - os dados não são armazenados, então como eles podem ser classificados? Uma visão é como um procedimento armazenado que contém apenas um SELECTsem parâmetros... ele não contém dados, apenas contém a definição da consulta. Como diferentes referências à exibição podem precisar de dados classificados de maneiras diferentes, a maneira como você faz isso - assim como selecionar em uma tabela, que também é uma coleção não classificada de linhas, por definição - é incluir a ordem na consulta externa .

Também para dar um pouco de visão sobre a história. Você nunca poderia colocar ORDER BYuma visão, sem incluir também TOP. E, neste caso, o ORDER BYditado quais linhas foram incluídas por TOP, não como elas seriam apresentadas. Aconteceu que no SQL Server 2000, se TOPera 100 PERCENTou {some number >= number of rows in the table}, o otimizador era bastante simplista e acabou produzindo um plano com uma classificação que correspondia ao TOP/ORDER BY. Mas esse comportamento nunca foi garantido ou documentado - foi apenas invocado com base na observação, o que é um mau hábito . Quando o SQL Server 2005 foi lançado, esse comportamento começou a "quebrar" por causa de mudanças no otimizador que levaram à utilização de diferentes planos e operadores - entre outras coisas, oTOP / ORDER BYseria ignorado completamente se fosse TOP 100 PERCENT. Alguns clientes reclamaram tanto disso que a Microsoft emitiu um sinalizador de rastreamento para restabelecer o comportamento antigo. Não vou dizer qual é o sinalizador porque não quero que você o use e quero ter certeza de que a intenção está correta - se você quiser uma ordem de classificação previsível, use ORDER BYna consulta externa.

Para resumir e também para esclarecer um ponto que você fez: a Microsoft não removeu nada. Eles melhoraram o produto e, como efeito colateral, esse comportamento não documentado e não garantido tornou-se menos confiável. No geral, acho que o produto é melhor para isso.

Se uma visão pudesse ser classificada, qual deveria ser a ordem do resultado aqui?

CREATE VIEW dbo.V1
AS
  SELECT number
  FROM   SomeTable
  ORDER  BY number ASC

GO

CREATE VIEW dbo.V2
AS
  SELECT number
  FROM   SomeTable
  ORDER  BY number DESC

GO

SELECT *
FROM   dbo.V1
       JOIN dbo.V2
         ON V1.number = V2.number 

uma possibilidade é evitar classificações conflitantes - se a exibição estiver classificando por uma ordem e o select nessa exibição estiver classificando por outra ordem (sem estar ciente da classificação da exibição), pode haver um impacto no desempenho. Portanto, é mais seguro deixar o requisito de classificação para o usuário.

outro motivo, a classificação vem com um custo de desempenho, então por que penalizar todos os usuários da visualização, quando apenas alguns usuários precisam da classificação?

O ANSI SQL permite apenas a ORDER BYconsulta externa por vários motivos, sendo um deles o que acontece quando uma subseleção/exibição/CTE é associada a outra tabela e a consulta externa possui uma ORDER BYprópria.

O servidor SQL nunca o suportou dentro de uma visão (a menos que você o tenha enganado usando um TOP 100 PERCENTque, na minha opinião, está acionando principalmente um bug).

Mesmo que você tenha acionado o bug, os resultados nunca foram confiáveis ​​e a classificação nem sempre saiu da maneira que você esperava.

Consulte esta postagem de blog da equipe do Otimizador de consultas para obter uma explicação técnica completa TOP 100% ORDER BY Considerado prejudicial.

A implementação do plano padrão para este código acontece para classificar as linhas como parte da execução da operação TOP. Muitas vezes, isso significava que os resultados eram retornados em ordem classificada, e isso levava os clientes a acreditar que havia uma garantia de que as linhas eram classificadas. Este não é realmente o caso. Se você quiser que as linhas sejam retornadas ao usuário em ordem de classificação, você precisa usar um ORDER BY no bloco de consulta mais externo (por ANSI) para garantir a ordem de apresentação de saída.

As visualizações se comportam como tabelas cujo conteúdo é determinado pelos resultados de uma consulta.

As tabelas não têm ordem; são apenas sacos de fileiras.

Portanto, as visualizações também não têm ordem. No entanto, você pode classificá-los selecionando linhas em um ORDER específico.

Uma resposta ainda não dada é que "ordenar por" pode interferir no envio de predicados, o que pode afetar muito o desempenho.

Um exemplo é ter uma visualização que acumula um grande conjunto de dados em um resumo de 10 linhas que é o top 10/Pedidos:

select * from TopOrderedView; -- Ordered 10 line summary in 5s

Para o mesmo caso com um predicado forte:

select * from TopOrderedView where <condition>; -- Ordered 2 line summary in still 5s

Ainda leva o mesmo tempo porque o top/order by está bloqueando a execução do predicado mais cedo no pipeline. Isso pode fazer com que linhas desnecessárias sejam processadas e o plano será semelhante ao sem predicado.

Se o push deve acontecer antes do pedido é realmente uma escolha do desenvolvedor e pode mudar a resposta. Na maioria das vezes, o impulso é a intenção lógica.

O uso de "top 100 por cento" permite logicamente o envio de predicado, mas a implementação infelizmente ignora "ordem por" para este caso e anula a intenção.

Para casos de uso reais, um bom compromisso seria o mecanismo executar "ordem puxando". Isso permitiria que uma "ordem por" fosse especificada na visualização (com 100 por cento superior ou sem parte superior) e essa ordem só seria usada se a visualização fosse selecionada diretamente, sem uma ordem explícita por, sem junções, sem agregações, sem encadeamento de visualizações etc. Ambos os casos listados acima podem ser suportados por este modelo simples.

você pode criar uma visão que tenha ordem por e preserve a ordem por quando consultada após:

selecione top 99.999999999999 por cento * de ..... peça por