Czy kiedykolwiek napotkał kwerendy SQL Server nie może wykonać, ponieważ odwołuje się zbyt wielu tabel?

głosy
15

Widzieliście kiedyś każdy z tam komunikaty o błędach?

- SQL Server 2000

Nie można przydzielić tabelę pomocniczą dla widoku lub rozmiar funkcyjnego.
Maksymalna liczba tablic w zapytaniu (256) został przekroczony.

- SQL Server 2005

Zbyt wiele nazw tabel w zapytaniu. Maksymalna dopuszczalna wynosi 256.

Jeśli tak, to co zrobiliście?

Poddać się? Przekonały klienta w celu uproszczenia ich żądań? Nieznormalizowane bazy danych?


@ (Wszyscy chcą mi odpowiedzieć na zapytanie):

  1. Nie jestem pewien, czy mogę wklejać 70 kilobajtów kodu w oknie edycji odpowiedź.
  2. Nawet jeśli może to nie pomoże, ponieważ to 70 kilobajtów kodu będzie odwoływać się 20 lub 30 widoki, że ja też mam odpowiedzieć, ponieważ w przeciwnym wypadku kod będzie bez znaczenia.

Nie chcę brzmieć jak jestem tutaj chluby, ale problem nie jest w zapytaniami. Zapytania są optymalne (lub przynajmniej prawie optymalny). Spędziłem wiele godzin ich optymalizacji, szukając każdej kolumnie i każdej pojedynczej tabeli, które mogą być usunięte. Wyobraźmy sobie raport, który zawiera 200 lub 300 kolumn, które mają być wypełnione jednym SELECT (bo tak to zostało zaprojektowane kilka lat temu, gdy był jeszcze mały raport).

Utwórz 05/08/2008 o 15:54
źródło użytkownik
W innych językach...                            


8 odpowiedzi

głosy
1

Nigdy nie spotkałem takiej sytuacji, i szczerze mówiąc pomysł o przedstawieniu> 256 tabel w zapytaniu fils mnie ze śmiertelnego strachu.

Twoje pierwsze pytanie należy prawdopodobnie przez „Dlaczego tak wielu?”, A tuż za „co bitów informacji mogę nie potrzebujemy?” Byłbym zaniepokojony, że ilość danych zwracanych z takiego zapytania zaczną wpływać na wydajność aplikacji całkiem poważnie, zbyt.

Odpowiedział 05/08/2008 o 15:57
źródło użytkownik

głosy
0

Chciałbym zobaczyć, że zapytanie, ale wyobrażam sobie, że to jakiś problem z jakimś iteracyjnej, a jednocześnie nie mogę myśleć o wszelkich sytuacjach, kiedy jego możliwości, założę się, że to od złej while / Case / kursora lub tonę źle wdrażane widoki.

Odpowiedział 05/08/2008 o 15:58
źródło użytkownik

głosy
1

@chopeen Można zmienić sposób jesteś obliczania tych statystyk i zamiast zachować odrębną tabelę wszystkich statystykach na produkt .. gdy zostanie złożone zamówienie, pętlę poprzez produkty i aktualizować odpowiednie rekordy w tabeli statystyk. To przesunięcie dużo obciążenia obliczeniowego na stronie transakcji zamiast działa wszystko w jednym ogromnym zapytania podczas uruchamiania raportu. Oczywiście istnieją pewne statystyki, które nie idą do pracy, a także w ten sposób, na przykład śledzenie klientów kolejnych zakupów po zakupie danego produktu.

Odpowiedział 05/08/2008 o 16:19
źródło użytkownik

głosy
8

SQL Server 2005, polecam za pomocą zmiennych tabeli i częściowo budowę dane jak przejść.

Aby to zrobić, należy utworzyć zmienną stołowego, który reprezentuje swój ostateczny wynik zestaw, który chcesz wysłać do użytkownika.

Następnie znajdź swój podstawowy tabeli (słownie tabeli Zamówienia w powyższym przykładzie) i wyciągnąć te dane, plus trochę dodatkowych danych, które są tylko powiedzieć jedno dołączyć dala (nazwa klienta, nazwa towaru). Można to zrobić SELECT INTO umieścić to prosto w zmiennej tabeli.

Stamtąd iterację tabeli i dla każdego wiersza, zrobić kilka małych zapytań SELECT, która pobiera wszystkie dane uzupełniające potrzeba do zbioru wynikowego. Włóż je do każdej kolumny, jak przejść.

Po zakończeniu, będzie można zrobić prosty select * from zmiennej tabeli i zwrócić ten zestaw wyników dla użytkownika.

Nie mam żadnych konkretnych liczb do tego, ale były trzy różne przypadki, że pracowali na bieżąco gdzie robią te mniejsze zapytań rzeczywiście pracował szybciej niż robi jeden ogromny kwerendę wybierającą z grupą łączy.

Odpowiedział 05/08/2008 o 16:19
źródło użytkownik

głosy
0

Opublikować zapytanie: D

Również czuję się jedną z możliwych problemów mogłoby być o ton (czytaj 200+) tabel nazwa / wartość, która mogłaby skondensowane w jednej tabeli.

Odpowiedział 05/08/2008 o 16:26
źródło użytkownik

głosy
1

To by było cały czas przy pisaniu raportów Reporting Services dla instalacji Dynamics CRM działających na SQL Server 2000. CRM ma ładnie znormalizowany schemat danych, co powoduje dużo łączy. Jest rzeczywiście poprawka, która będzie się wokół granicy od 256 do aż o 260: http://support.microsoft.com/kb/818406 (zawsze, że to świetny żart ze strony zespołu SQL Server).

Rozwiązaniem, jak aludes Dillie-O, jest, aby zidentyfikować odpowiednie „sub-dołącza” (najlepiej te, które są wykorzystywane wielokrotnie) i czynnik je do zmiennych temp-stołowych, które następnie wykorzystują w głównym łączy. Jest to poważny PIA i często zabija wydajność. Przykro mi.

@Kevin, kocham ten trójnik - mówi wszystko :-).

Odpowiedział 02/11/2008 o 16:50
źródło użytkownik

głosy
0

Miałem ten sam problem ... moja skrzynka rozwój przebiega SQL Server 2008 (widok działało w porządku), ale na produkcji (SQL Server 2005) widok nie. Skończyło się tworzenia widoków, aby uniknąć tego ograniczenia, wykorzystując nowe widoki jako część kwerendy w widoku, który rzucił ten błąd.

Trochę głupie biorąc pod uwagę wykonanie logiczny jest taki sam ...

Odpowiedział 19/08/2010 o 18:29
źródło użytkownik

głosy
0

Miałem ten sam problem w SQL Server 2005 (pracował w 2008 roku), gdy chciałem utworzyć widok. I rozwiązany poprzez stworzenie procedury przechowywanej zamiast widoku.

Odpowiedział 07/03/2012 o 16:59
źródło użytkownik

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