Har du noen gang møtt en spørring som SQL Server ikke kan kjøre fordi den refererte for mange bord?

stemmer
15

Har du noen gang sett noen av det feilmeldinger?

- SQL Server 2000

Kunne ikke bevilge hjelpebord for visning eller funksjon oppløsning.
Det maksimale antall bord i en spørring (256) ble overskredet.

- SQL Server 2005

For mange tabellnavnene i søket. Den maksimalt tillatte er 256.

Hvis ja, hva har du gjort?

Gitt opp? Overbevist kunden å forenkle deres krav? Denormalized databasen?


@ (Alle som ønsker meg å legge spørringen):

  1. Jeg er ikke sikker på om jeg kan lime 70 kilobyte med kode i svaret redigeringsvinduet.
  2. Selv om jeg kan dette dette ikke vil hjelpe siden denne 70 kilobyte med kode vil referere til 20 eller 30 visninger som jeg også ville ha til å poste siden ellers koden vil være meningsløst.

Jeg ønsker ikke å høres ut som jeg kan skryte av her, men problemet er ikke i spørringer. Søkene er optimal (eller i det minste nesten optimal). Jeg har tilbrakt utallige timer å optimalisere dem, på jakt etter hver enkelt kolonne og hver enkelt tabell som kan fjernes. Tenk deg en rapport som har 200 eller 300 kolonner som må fylles med et enkelt SELECT-setning (fordi det er hvordan det er designet for noen år siden da det var fortsatt en liten rapport).

Publisert på 05/08/2008 klokken 14:54
kilden bruker
På andre språk...                            


8 svar

stemmer
8

For SQL Server 2005, vil jeg anbefale å bruke bord variabler og delvis bygge dataene som du går.

For å gjøre dette, opprette en tabell variabel som representerer den endelige resultatsettet du ønsker å sende til brukeren.

Så finn din primære tabellen (si ordretabellen i eksempelet ovenfor) og trekk at data, pluss en bit av tilleggsdata som bare si en bli borte (kundenavn, produktnavn). Du kan gjøre en SELECT INTO å sette dette rett inn i din tabell variabel.

Derfra iterere gjennom tabellen og for hver rad, gjør en haug med små SELECT spørringer som henter alle supplerende data du trenger for resultatsettet. Sett disse inn i hver kolonne som du går.

Når du er ferdig, kan du gjøre en enkel SELECT * fra tabellen variable og returnere dette resultatet satt til brukeren.

Jeg har ikke noen harde tall for dette, men det har vært tre forskjellige tilfeller som jeg har jobbet med å date der å gjøre disse små spørsmål har faktisk jobbet raskere enn å gjøre en massiv velger søket med en haug med tiltrer.

Svarte 05/08/2008 kl. 15:19
kilden bruker

stemmer
1

Dette vil skje hele tiden når du skriver Reporting Services-rapporter for Dynamics CRM installasjoner som kjører på SQL Server 2000. CRM har et pent normalisert data skjema som resulterer i en rekke møter. Det er faktisk en hurtigreparasjon rundt som vil opp grensen fra 256 til hele 260: http://support.microsoft.com/kb/818406 (vi har alltid trodd dette en stor vits på den delen av SQL Server-teamet).

Løsningen, som Dillie-O Aludes til, er å identifisere passende "sub-tiltrer" (fortrinnsvis de som brukes flere ganger) og faktor dem ut i temp-tabellen variabler som du deretter bruker i hoved tiltrer. Det er en stor PIA og ofte dreper ytelse. Jeg er lei for deg.

@Kevin, elsker at tee - sier alt :-).

Svarte 02/11/2008 kl. 15:50
kilden bruker

stemmer
1

@chopeen Du kan endre måten du beregne denne statistikken, og i stedet holde en egen tabell over alle pr-produkt statistikk .. når en ordre er plassert, sløyfe gjennom produktene og oppdatere de aktuelle postene i statistikktabellen. Dette ville skifte mye beregningen belastningen til kassen stedet for å kjøre alt i en stor spørring når du kjører en rapport. Selvfølgelig er det noen statistikk som ikke kommer til å fungere så bra på denne måten, f.eks spore kundenes neste kjøp etter å kjøpe et bestemt produkt.

Svarte 05/08/2008 kl. 15:19
kilden bruker

stemmer
1

Jeg har aldri kommet over en slik situasjon, og for å være ærlig ideen på å registrere> 256 tabeller i en spørring fils meg med en dødsangst.

Din første spørsmålet bør nok av "Hvorfor så mange?", Tett etterfulgt av "hva biter av informasjon har jeg ikke trenger?" Jeg ville være bekymret for at mengden data som blir returnert fra et slikt søk vil begynne å påvirke ytelsen til programmet ganske alvorlig, også.

Svarte 05/08/2008 kl. 14:57
kilden bruker

stemmer
0

Hadde det samme problemet i SQL Server 2005 (jobbet i 2008) da jeg ønsket å lage en visning. I løst problemet ved å opprette en lagret prosedyre i stedet for en visning.

Svarte 07/03/2012 kl. 15:59
kilden bruker

stemmer
0

Jeg hadde samme problemet ... min utvikling boksen kjører SQL Server 2008 (visningen fungerte fint), men på produksjon (med SQL Server 2005) utsikten gjorde ikke. Jeg endte opp med å skape visninger for å unngå denne begrensningen, ved hjelp av nye visninger som en del av spørringen i visningen som kastet feilen.

Litt dumt med tanke på logiske utførelsen er det samme ...

Svarte 19/08/2010 kl. 17:29
kilden bruker

stemmer
0

Post spørringen: D

Også føler som en av de mulige problemer kan være å ha et tonn (les 200 +) av navn / verditabeller som kan kondenseres til en enkelt oppslagstabellen.

Svarte 05/08/2008 kl. 15:26
kilden bruker

stemmer
0

Jeg vil gjerne se at spørringen, men jeg antar det er noe problem med en slags iterator, og mens jeg ikke kan komme på noen situasjoner der det er mulig, jeg vedder på at det er fra en dårlig mens / case / markøren eller massevis av dårlig implementert utsikt.

Svarte 05/08/2008 kl. 14:58
kilden bruker

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