Avete mai incontrato una query che SQL Server non può eseguire perché fa riferimento troppi tavoli?

voti
15

Avete mai visto uno qualsiasi dei messaggi di errore là?

- SQL Server 2000

Impossibile allocare la tabella ausiliaria per la visualizzazione o la risoluzione della funzione.
È stato superato il numero massimo di tabelle in una query (256).

- SQL Server 2005

Troppi nomi di tabella nella query. Il massimo consentito è 256.

Se sì, che cosa hai fatto?

Mollato? Convinto il cliente per semplificare le loro richieste? Denormalizzato il database?


@ (Tutti mi vogliono inviare la query):

  1. Non sono sicuro se posso incollare 70 kilobyte di codice nella finestra di modifica risposta.
  2. Anche se posso presente questo non aiuterà poiché questo 70 kilobyte di codice farà riferimento 20 o 30 punti di vista che mi avrebbe anche di inviare in quanto altrimenti il ​​codice sarà priva di significato.

Non voglio suonare come sto vanto qui, ma il problema non è nelle query. Le query sono ottimali (o almeno quasi ottimale). Ho passato ore e ore ottimizzandoli, alla ricerca di ogni singola colonna e ogni singolo tavolo che può essere rimosso. Immaginate un report che dispone di 200 o 300 colonne che deve essere riempito con una singola istruzione SELECT (perché è così che è stato progettato a pochi anni fa, quando era ancora un piccolo report).

È pubblicato 05/08/2008 alle 15:54
fonte dall'utente
In altre lingue...                            


8 risposte

voti
1

Non ho mai incontrato questo tipo di situazione, e ad essere onesti l'idea di riferimento> 256 tabelle in una query mi fils con un terrore mortale.

La tua prima domanda dovrebbe probabilmente da "Perché così tanti?", Seguito da vicino da "ciò che i bit di informazioni posso non serve?" Sarei preoccupato che la quantità di dati che vengono restituiti da una query avrebbe cominciato a influire sulle prestazioni dell'applicazione piuttosto grave, anche.

Risposto il 05/08/2008 a 15:57
fonte dall'utente

voti
0

Mi piacerebbe vedere quella domanda, ma immagino che sia qualche problema con una sorta di iteratore, e mentre io non riesco a pensare a situazioni in cui il suo possibile, scommetto che è da un male mentre / caso / cursore o una tonnellata di mal implementato vista.

Risposto il 05/08/2008 a 15:58
fonte dall'utente

voti
1

@chopeen Si potrebbe cambiare il modo in cui si sta calcolando queste statistiche, e invece mantenere una tabella separata di tutte le statistiche per-prodotto .. quando viene fatto un ordine, un ciclo tra i prodotti e aggiornare i record appropriati nella tabella statistiche. Questo sposterebbe un sacco di carico di calcolo alla pagina di checkout, piuttosto che correre tutto in un enorme di query durante l'esecuzione di un report. Naturalmente ci sono alcune statistiche che non vanno a lavorare così in questo modo, ad esempio, il monitoraggio dei clienti prossimi acquisti dopo l'acquisto di un determinato prodotto.

Risposto il 05/08/2008 a 16:19
fonte dall'utente

voti
8

Per SQL Server 2005, mi consiglia di utilizzare le variabili di tabella e in parte la costruzione dei dati, come si va.

Per fare questo, creare una variabile di tabella che rappresenta il set di risultati finale che si desidera inviare all'utente.

Poi trovare la tua tabella primaria (ad esempio la tabella di ordini nel tuo esempio di cui sopra) e tirare i dati, oltre a un po 'di dati supplementari che è dire solo una join di distanza (il nome del cliente, il nome del prodotto). Si può fare un SELECT INTO per mettere questo direttamente nel tuo variabile di tabella.

Da lì, scorrere la tavola e per ogni riga, fare un gruppo di piccoli query SELECT che recupera tutti i dati supplementare necessario per il vostro set di risultati. Inserire questi in ogni colonna, come si va.

Una volta completato, si può poi fare una semplice SELECT * dal variabile di tabella e restituire questo set di risultati per l'utente.

Non ho alcun numero duramente per questo, ma ci sono stati tre casi distinti che ho lavorato fino ad oggi in cui fare queste query più piccola ha effettivamente lavorato più veloce di fare una massiccia query di selezione con un gruppo di join.

Risposto il 05/08/2008 a 16:19
fonte dall'utente

voti
0

Pubblica la query: D

Inoltre mi sento come uno dei possibili problemi potrebbe essere avere una tonnellata (leggi 200 +) di tabelle nome / valore che potrebbe condensati in un'unica tabella di ricerca.

Risposto il 05/08/2008 a 16:26
fonte dall'utente

voti
1

Ciò accadrebbe per tutto il tempo durante la scrittura di report di Reporting Services per le installazioni Dynamics CRM in esecuzione su SQL Server 2000. CRM ha uno schema di dati ben normalizzato che si traduce in un sacco di join. In realtà c'è una correzione intorno a quella volontà il limite da 256 a un enorme 260: http://support.microsoft.com/kb/818406 (abbiamo sempre pensato questo un grande scherzo da parte del team di SQL Server).

La soluzione, come aludes Dillie-O a, è quello di individuare appropriata "sub-join" (preferibilmente quelli che vengono utilizzati più volte) e fattore di fuori in variabili temp-tavolo che poi utilizza in si unisce alla tua principale. Si tratta di un importante PIA e spesso uccide le prestazioni. Mi dispiace per te.

@ Kevin, amore che tee - dice tutto :-).

Risposto il 02/11/2008 a 16:50
fonte dall'utente

voti
0

Ho avuto questo stesso problema ... la mia casella di sviluppo esegue SQL Server 2008 (la vista ha funzionato bene), ma sulla produzione (con SQL Server 2005) la vista non ha fatto. Ho finito per la creazione di viste per evitare questa limitazione, utilizzando le nuove viste come parte della query nella vista che ha gettato l'errore.

Tipo di stupido considerare l'esecuzione logica è la stessa ...

Risposto il 19/08/2010 a 18:29
fonte dall'utente

voti
0

Ha avuto lo stesso problema in SQL Server 2005 (ha lavorato nel 2008), quando ho voluto creare una vista. Ho risolto il problema creando una stored procedure, invece di una vista.

Risposto il 07/03/2012 a 16:59
fonte dall'utente

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