Zastanawiałem się nad użyciem widoków indeksowanych, aby zwiększyć wydajność kilku najczęściej używanych widoków.
Widoki indeksowane nie obsługują jednak nieunikalnych indeksów klastrowych, co jest nieco sprzeczne z priorytetem ustawionym przez resztę struktury bazy danych.
Na przykład, oto uproszczona wersja kilku naszych tabel.
-Groups-
Group ID GroupName
-Users-
UserKey UserName FullName GroupID
Indeksy znajdują się na Groups.GroupID (nieklastrowany) i Users.GroupID (klastrowany). Klucz klastrowany znajdujący się na GroupID w tabeli Users, ponieważ najczęściej pobierany byłby zakres użytkowników z określonej grupy. Oczywiście miałbyś wielu użytkowników na grupę, więc ten indeks klastrowy nie jest unikalny.
To sprawia, że jestem trochę niepewny, jak przestrzegać tego pierwszeństwa podczas indeksowania moich widoków, takich jak ten przykład, ponieważ nie mogę mieć nieunikalnego indeksu klastrowego.
ConsumableID ConsumableVariantID AllowThresholdOverwrite FullPath GroupID ManufacturerID Type ModelID
101 29 1 0.1.2.4. 4 3 3 2
W rzeczywistości jedyną wartością w tym widoku, która zawsze byłaby unikalna, jest kolumna ConsumableID, więc nie mam wyboru, gdzie umieścić mój indeks.
Dlaczego widoki nie zezwalają na niejednorodne indeksy klastrowe, gdy robią to zwykłe tabele?
(GroupID, UserID). Nie ograniczaj się do pojedynczej kolumny dla klucza. 2 - Wyobrażam sobie, że ograniczeniem widoku jest to, że jest to dodatkowy obiekt danych, który musi mieć łatwo powiązane wiersze z indeksami NC. W przypadku tabeli dołączany jest nieunikalny klucz CI, ale myślę, że byłoby to trudniejsze w przypadku widoku indeksowanego, ponieważ nie jest to rzeczywista tabela, ale musi ona ODBRAĆ rzeczywistą tabelę.