Você já encontrou uma consulta que o SQL Server não conseguiu executar porque fazia referência a muitas tabelas?

Question

Você já viu alguma dessas mensagens de erro?

- SQLServer 2000

Não foi possível alocar tabela auxiliar para visualização ou resolução de função.
O número máximo de tabelas em uma consulta (256) foi excedido.

-- SQLServer 2005

Muitos nomes de tabela na consulta.O máximo permitido é 256.

Se sim, o que você fez?

Desistir?Convenceu o cliente a simplificar suas demandas?Desnormalizou o banco de dados?

---

@(todos querendo que eu poste a consulta):

1. Não tenho certeza se consigo colar 70 kilobytes de código na janela de edição de respostas.
2. Mesmo que eu consiga, isso não vai ajudar, já que esses 70 kilobytes de código farão referência a 20 ou 30 visualizações que eu também teria que postar, caso contrário o código não teria sentido.

Não quero parecer que estou me gabando aqui, mas o problema não está nas consultas.As consultas são ótimas (ou pelo menos quase ótimas).Passei inúmeras horas otimizando-os, procurando cada coluna e cada tabela que pudesse ser removida.Imagine um relatório que possui 200 ou 300 colunas que devem ser preenchidas com uma única instrução SELECT (porque foi assim que foi concebido há alguns anos, quando ainda era um relatório pequeno).

Answer 1

Para o SQL Server 2005, recomendo usar variáveis ​​de tabela e construir parcialmente os dados conforme você avança.

Para fazer isso, crie uma variável de tabela que represente o conjunto de resultados finais que você deseja enviar ao usuário.

Em seguida, encontre sua tabela principal (digamos, a tabela de pedidos no exemplo acima) e extraia esses dados, além de alguns dados suplementares que estão a apenas uma junção de distância (nome do cliente, nome do produto).Você pode fazer um SELECT INTO para colocar isso direto na variável da sua tabela.

A partir daí, percorra a tabela e, para cada linha, faça várias pequenas consultas SELECT que recuperam todos os dados suplementares necessários para o seu conjunto de resultados.Insira-os em cada coluna à medida que avança.

Depois de concluído, você pode fazer um simples SELECT * na variável da tabela e retornar esse conjunto de resultados ao usuário.

Não tenho números concretos para isso, mas houve três casos distintos em que trabalhei até agora em que fazer essas consultas menores realmente funcionou mais rápido do que fazer uma consulta de seleção massiva com um monte de junções.

Answer 2

Nunca me deparei com esse tipo de situação e, para ser honesto, a ideia de referenciar mais de 256 tabelas em uma consulta me causa um pavor mortal.

Sua primeira pergunta provavelmente deveria ser "Por que tantas?", seguida de perto por "que informações devo NÃO precisa?" Eu ficaria preocupado que a quantidade de dados retornados de tal consulta também começasse a afetar severamente o desempenho do aplicativo.

Answer 3

@chopeen Você pode mudar a maneira como calcula essas estatísticas e, em vez disso, manter uma tabela separada de todas as estatísticas por produto.quando um pedido for feito, percorra os produtos e atualize os registros apropriados na tabela de estatísticas.Isso transferiria grande parte da carga de cálculo para a página de checkout, em vez de executar tudo em uma consulta enorme ao executar um relatório.É claro que existem algumas estatísticas que não funcionarão tão bem desta forma, por ex.rastrear as próximas compras dos clientes após a compra de um determinado produto.

Answer 4

Isso acontecia o tempo todo ao escrever relatórios do Reporting Services para instalações do Dynamics CRM em execução no SQL Server 2000.O CRM possui um esquema de dados bem normalizado que resulta em muitas junções.Na verdade, existe um hotfix que aumentará o limite de 256 para impressionantes 260: http://support.microsoft.com/kb/818406 (sempre achamos isso uma ótima piada da equipe do SQL Server).

A solução, como Dillie-O alude, é identificar "subjunções" apropriadas (de preferência aquelas que são usadas várias vezes) e fatorá-las em variáveis ​​de tabela temporária que você usa em suas junções principais.É uma PIA importante e muitas vezes prejudica o desempenho.Eu sinto muito por você.

@Kevin, adorei essa camiseta - diz tudo :-).

Answer 5

Eu gostaria de ver essa consulta, mas imagino que seja algum problema com algum tipo de iterador e, embora não consiga pensar em nenhuma situação em que seja possível, aposto que é de um while/case/cursor ruim ou de uma tonelada de visões mal implementadas.

Answer 6

Poste a consulta :D

Também sinto que um dos possíveis problemas poderia ser ter uma tonelada (leia mais de 200) de tabelas de nome/valor que poderiam ser condensadas em uma única tabela de pesquisa.

Answer 7

Eu tenho esse mesmo problema...minha caixa de desenvolvimento executa o SQL Server 2008 (a visualização funcionou bem), mas na produção (com o SQL Server 2005) a visualização não.Acabei criando visualizações para evitar essa limitação, usando as novas visualizações como parte da consulta na visualização que gerou o erro.

Meio bobo, considerando que a execução lógica é a mesma...

Answer 8

Tive o mesmo problema no SQL Server 2005 (funcionou em 2008) quando quis criar uma visualização.Resolvi o problema criando um procedimento armazenado em vez de uma visualização.