Você já encontrou uma consulta que o SQL Server não pôde executar porque referencia muitas tabelas?

votos
15

Você já viu qualquer de mensagens de erro?

- SQL Server 2000

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

- SQL Server 2005

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

Se sim, o que você fez?

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


@ (Todos me querer postar a consulta):

  1. Eu não tenho certeza se eu pode colar 70 kilobytes de código na janela de resposta edição.
  2. Mesmo se eu posso neste isso não vai ajudar uma vez que este 70 kilobytes de código fará referência 20 ou 30 pontos de vista que eu também teria que publicar pois caso contrário o código será inútil.

Eu não quero soar como eu estou apresentando aqui, mas o problema não está nas consultas. As consultas são ideais (ou pelo menos quase ideal). Eu passei incontáveis ​​horas otimizando-os, procurando cada coluna e cada mesa única que pode ser removida. Imagine um relatório que tem 200 ou 300 colunas que tem de ser preenchido com uma única instrução SELECT (porque é assim que foi concebido há alguns anos, quando ainda era um pequeno relatório).

Publicado 05/08/2008 em 15:54
fonte usuário
Em outras línguas...                            


8 respostas

votos
8

Para o SQL Server 2005, eu recomendo usar variáveis ​​de tabela e parcialmente construir os dados que você vá.

Para fazer isso, crie uma variável de tabela que representa o conjunto de resultado final que deseja enviar para o usuário.

Em seguida, encontrar o seu tabela primária (digamos tabela de pedidos no seu exemplo acima) e puxar esses dados, além de um pouco de dados suplementares que só é dizer uma juntar-se afastado (nome do cliente, nome do produto). Você pode fazer um SELECT INTO para colocar isso em linha reta em sua variável de tabela.

De lá, percorrer a mesa e para cada linha, fazer um monte de pequenas consultas SELECT que recupera todos os dados suplementares que você precisa para o seu conjunto de resultados. Inseri-las em cada coluna que você vá.

Uma vez completo, você pode então fazer um simples SELECT * de sua variável de tabela e retornar este conjunto de resultados para o usuário.

Eu não tenho quaisquer números concretos para isso, mas houve três casos distintos que tenho trabalhado para data onde fazer essas consultas menores tem realmente trabalhou mais rápido do que fazer uma consulta seleção enorme com um monte de junta.

Respondeu 05/08/2008 em 16:19
fonte usuário

votos
1

Isso acontece o tempo todo quando se escreve Relatórios do Reporting Services para instalações Dynamics CRM em execução no SQL Server 2000. CRM tem um esquema de dados bem normalizado o que resulta em um monte de junta. Na verdade, há uma correcção em torno dessa vontade até o limite de 256 para uma gritante 260: http://support.microsoft.com/kb/818406 (sempre pensei que isso uma grande piada por parte da equipe do SQL Server).

A solução, como Aludes Dillie-S para, é identificar apropriado "sub-junta" (de preferência aqueles que são usados ​​várias vezes) eo fator-los em variáveis ​​temp-table que você, em seguida, usar em seu principal une. É um grande PIA e muitas vezes mata desempenho. Sinto muito por você.

@ Kevin, o amor que tee - diz tudo :-).

Respondeu 02/11/2008 em 16:50
fonte usuário

votos
1

@chopeen Você poderia mudar a maneira como você está calculando estas estatísticas, e em vez disso manter uma tabela separada de todas as estatísticas por produto .. quando um pedido é feito, percorrer os produtos e atualizar os registros apropriados na tabela de estatísticas. Isso mudaria muito a carga de cálculo para a página de pagamento ao invés de executar tudo em uma consulta enorme ao executar um relatório. Claro que existem algumas estatísticas que não vão funcionar tão bem desta forma, por exemplo, rastreamento próximos compras dos clientes após a compra de um determinado produto.

Respondeu 05/08/2008 em 16:19
fonte usuário

votos
1

Eu nunca se deparar com esse tipo de situação, e para ser honesto a idéia em referenciar> 256 tabelas em uma consulta me fils com um medo mortal.

Sua primeira pergunta deve provavelmente por "Por que tantos?", Seguido de perto por "o que pedaços de informações que eu não precisa?" Eu ficaria preocupado que a quantidade de dados a serem devolvidos a partir de uma consulta, iria começar a afetar o desempenho do aplicativo severamente, também.

Respondeu 05/08/2008 em 15:57
fonte usuário

votos
0

Tive o mesmo problema no SQL Server 2005 (trabalhou em 2008) quando eu queria criar uma visão. I resolveu o problema criando um procedimento armazenado em vez de um ponto de vista.

Respondeu 07/03/2012 em 16:59
fonte usuário

votos
0

Eu tive esse mesmo problema ... minha caixa de desenvolvimento executa o SQL Server 2008 (o ponto de vista funcionou bem), mas sobre a produção (com o SQL Server 2005) a vista não fez. I acabou criando pontos de vista para evitar essa limitação, usando as novas vistas como parte da consulta na vista que jogou o erro.

Tipo de considerar tola a execução lógica é a mesma ...

Respondeu 19/08/2010 em 18:29
fonte usuário

votos
0

Postar a consulta: D

Também eu me sinto como um dos possíveis problemas poderiam estar tendo uma tonelada (leia-200 +) de tabelas nome / valor que poderia condensadas em uma única tabela de pesquisa.

Respondeu 05/08/2008 em 16:26
fonte usuário

votos
0

Eu gostaria de ver essa consulta, mas eu imagino que é algum problema com algum tipo de iterador, e enquanto eu não consigo pensar em quaisquer situações onde a sua possível, eu aposto que é de um tempo ruim / case / cursor ou uma tonelada de visualizações mal implementado.

Respondeu 05/08/2008 em 15:58
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more