none
Too many table names in the query. The maximum allowable is 256, o que seria isso ???? RRS feed

  • Pergunta

  • Server: Msg 106, Level 15, State 1, Line 298
    Too many table names in the query. The maximum allowable is 256.
    Server: Msg 170, Level 15, State 1, Line 365
    Line 365: Incorrect syntax near ')'.

     

    Esse erro foi retornado no query analyser, pois estou precisando fazer um select dessa forma:

     

    Se eu rodar a query mais pesada que é a mais interna que eu chamei de 3 funciona normalmente, as mais externas tem poucos campos.

     

    1) Select campos.... From (

    2) Select maiscampos......From(

    3 )Select campos mais internos... from Tabela

    join...

    ....

    ) as S1

    As S2

     

     

     

    Desde já agradeço, estou precisando resolver isso urgente.

     

    Abraços

     

    Adriano

     

    terça-feira, 19 de fevereiro de 2008 13:21

Todas as Respostas

  • Bom dia Adriano, não creio que existam 256 nomes de tabelas, porém, por questões de desempenho se fosse você alteraria esta estrutura e utilizaria um SP para encapsular a complexidade.

     

     

     

     

    Espero ter ajudado

     

    terça-feira, 19 de fevereiro de 2008 13:30
  • Olá Anderson, bom dia.

     

    Na verdade Anderson eu contei aqui e deu 168 tabelas, ou seja, para 256, ainda restam algumas tabelas.

     

    Vou verificar se consigo usar SP, não tenho certeza se dessa forma vou conseguir, mas, não custa tentar.

     

    Alguém alguém mais tiver alguma idéia, agradeço.

     

    Abraços,

     

    Adriano

    terça-feira, 19 de fevereiro de 2008 13:42
  • Bom Dia,

     

    O máximo de tabelas utilizadas em uma query é 256 tabelas. Mas esse número não inclui apenas as tabelas referenciadas. Devem ser considerados as tabelas derivadas (SELECTs de SELECTs) e no caso de referenciar Views, todas as tabelas dentro da View também são contadas).

     

    Se ainda assim você acha que não atinge as 256 tabelas, recomendo verificar se aplicou o último Service Pack do produto. Se você acha que atingiu esse número reescreva sua consulta.

     

    Mesmo que esse número não seja atingido, dificilmente uma Query referencia mais de 10 tabelas (168 é um número inaceitável para qualquer SGBD relacional). Quando isso ocorre, problemas podem estar presentes:

     

    Armazenamento Temporário

    Para diminuir a complexidade da consulta e as referências às tabelas, armazene parte da consulta em uma tabela temporária.

     

    Não utilização de funcionalidades

    O SQL Server dispõe de recursos como Views Indexadas e Coberturas de Índices para otimizar consultas. Considere utilizá-los para diminuir a quantidade de JOINs e funções sobre a consulta. É preciso levar em consideração também o impacto que eles provocarão em instruções de atualização (INSERT, UPDATE, DELETE).

     

    Normalização exagerada

    Se você chegou até a 5ª forma normal, conceitualmente falando o seu modelo está perfeito, mas fisicamente falando você pode estar com uma implementação ruim. Considere reduzir o nível de normalização para a 4ª forma norma, a FNBC ou a 3ª forma normal ou até desnormalizar algumas tabelas.

     

    Propósito Equivocado

    Se você se ver projetando queries com muitos JOINs, COUNTs, GROUP By, etc talvez você esteja com um banco de dados projetado para outro fim. Muitos JOINs são característicos de sistemas OLTP para privilegiar as atualizações. Se consultas pesadas juntando várias tabelas são executadas, considere utilizar um outro repositório como um ODS ou um DataWarehouse

     

    [ ]s,

     

    Gustavo

    terça-feira, 19 de fevereiro de 2008 13:46
  • Olá Gustavo, tudo bem?

     

    Cheguei nesse número, devido a necessidade de sumarizar dados de todas as filiais, tenho 16 filiais e cada filial possui suas próprias tabela de vendas, itens de estoque, itens de vendas familias de estoque e etc, dai esse número grande join e union all, foi por esse motivo que cheguei a esse número grande de tabelas.

     

    Se eu desconsiderar os dois primeiros select a query funciona normalmente embora tenha bastante join e union all o problema está no ponto onde trato o resultado dessa query mais interna, que seriam os itens 1) e dois que eu citei no inicio.

     

    Abraços,

     

    Adriano

     

    terça-feira, 19 de fevereiro de 2008 13:55
  • Olá Adriano,

     

    Se a situação é essa, você está usando os meios inadequados. É bastante comum situações como a sua acontecer. Desenvolve-se um sistema, distribui-se o sistema e no final querer-se-á juntar todos os dados para obter uma visão mais gerencial sobre o negócio (aquele típico relatório completo para o presidente da empresa). Não há nada de errado nisso e nem no fato de você querer (e precisar) gerar essas informações. No entanto há um conflito presente aí.

     

    Para haver tantas tabelas, é por que o sistema foi criado para pequenas operações (cadastro de produtos, manutenção de vendas, atualização de itens no estoque, etc). Quando se deseja realmente extrair dados que combinem praticamente todas as tabelas, não há SGBD que agüente.

     

    Nesse caso, eu recomendaria que você de tempos em tempos (uma vez por dia, duas vezes ao dia, de hora em hora, etc) você extraia os dados de cada filial e os jogue em um banco de dados isolado (ou até em um servidor isolado). Como os dados já estarão isolados em tabelas sumarizadas, quando você for juntá-las, as consultas ficarão mais simples e mais leves. A desvantagem é que a informação ficará um pouco desatualizada, mas acho que para um relatório desse tipo não é preciso ter uma precisão tão grande.

     

    O fato é que elaborar uma consulta dessas diretamente contra as tabelas de produção não é algo viável (mesmo que você consiga superar a limitação de 256 tabelas de alguma forma). Você estará penalizando todo o sistema por conta de uma única consultas (locks, esgotamento de memória, maior consumo de I/O, etc).

     

    [ ]s,

     

    Gustavo

     

    terça-feira, 19 de fevereiro de 2008 14:08