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

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.

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.

@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.

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.

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 :-).

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 ...

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.