Czy klucz partycji również musi być częścią klucza podstawowego?

Czy partycjonuję tabelę na podstawie kolumny, która nie jest kluczem podstawowym? Przeczytałem dzisiaj sprzeczne informacje na temat tego, czy kolumna partycji musi być częścią klucza podstawowego. Moje wnętrzności mówią nie, ale nie jestem w 100% pewien. Więc pytania ...

Czy kolumna partycji musi być częścią podstawowej? Czy jest to zalecane w ten czy inny sposób?
Czy muszę utworzyć indeks dla klucza partycji, czy też DBMS robi to automatycznie?

— AngryHacker
źródło

Odpowiedzi:

Ani trochę.

Jednym z najczęstszych scenariuszy partycjonowania jest użycie pola daty, które jest całkowicie niezwiązane z twoim PK.

Na przykład, jeśli masz tabelę Ordersz polem OrderDate, najprawdopodobniej podzielisz partycję na podstawie miesiąca i roku OrderDate.

Kiedy rekordy się zestarzeją i nie są już istotne, możesz przenieść te partycje do tabeli archiwum lub bazy danych, aby nie były już przetwarzane.

Partycjonowanie będzie działać z prawie każdym polem, ale aby działało DOBRZE, pola, na których partycjonujesz, powinny być używane w większości zapytań, jeśli nie we wszystkich. Jeśli nie podasz kluczy partycji, otrzymasz zasadniczo kosztowny skan tabeli, który przechodzi przez wiele tabel (partycji).

EDYTOWAĆ

W przypadku części drugiej myślę, że odpowiedź jest przecząca. Klucz partycji służy do określenia, w której partycji należy umieścić wiersz, ale nie sądzę, aby indeks był utrzymywany. Mogą być na nim statystyki.

— JNK
źródło

Wiem, że to jest stare, ale prowadzi mnie złą ścieżką, więc pomyślałem, że będę komentować dla innych. Kolumna partycji musi znajdować się w kluczu podstawowym, jeśli chcesz korzystać z możliwości PRZEŁĄCZANIA funkcji partycji. Jeśli nie ma go w kluczu podstawowym, pojawi się następujący błąd: Partition columns for a unique index must be a subset of the index key.

— Vaccano

Zgadzam się z @Vaccano

— san

Oprócz odpowiedzi JNK, prawdopodobnie powinieneś przeczytać ten artykuł, który omawia wyrównywanie partycji tabel i indeksów.

Istnieje wiele rodzajów scenariuszy, w których schemat partycjonowania jest dokładnie zgodny z pierwszą kolumną klucza podstawowego - na przykład w scenariuszu hurtowni danych, w którym datą migawki tabeli faktów jest zwykle kolumna partycji, a także pierwsza kolumna w kluczu podstawowym.

Ale również w środowiskach OLTP, w których PK jest TOŻSAMOŚCIĄ lub innym kluczem zastępczym, nie ma sensu używać tego dla partycji, ponieważ partycjonowanie na dowolnych liczbach zwykle nie jest strasznie przydatne. W systemach OLTP również najczęściej dzielisz według daty (prawdopodobnie nie w PK), ale potencjalnie także regionalnie lub według jakiegoś podziału organizacyjnego (być może w PK, jeśli nie korzystasz z surogatu).

Ale to nie jest wymóg.

— Cade Roux
źródło

Cóż, wiele rzeczy nie jest wymogiem. Nawet indeksowanie nie jest wymagane! Aby mieć sens pod względem funkcjonalnym, partycjonowanie należy wykonać w kolumnie wiodącej klucza kandydującego. W przeciwnym razie, jak architekt aplikacji użyłby tabeli?

— srini.venigalla,

@ srini.venigalla To częsty przypadek, ale innym powszechnym przypadkiem (tak samo?) jest partycjonowanie na czymś, co w ogóle nie jest częścią klucza głównego lub kandydującego - ponieważ partycjonowanie jest często używane do archiwizacji, data ważności może być dobry wybór partycji. Ale nie ma nic, co sugerowałoby, że może być częścią klucza. Partycjonowanie to funkcja niskiego poziomu, która jest dość ogólna i istnieją co najmniej dwa odrębne i sprzeczne wzorce użytkowania, z których oba mają uzasadnione najlepsze praktyki wokół nich.

— Cade Roux,

Musi być częścią klucza kandydackiego, jeśli nie częścią samego klucza podstawowego. Pomysł polega na tym, że partycjonowanie powinno wyrównać się z kluczem podstawowym.

Tak więc odpowiedź brzmi: tak, najlepiej być częścią PK. Jeśli nie inny klucz, który jest równie dobry, aby być PK.

— srini.venigalla
źródło

Nigdy nie słyszałem o Kluczu Kandydata. Jak określa się to w instrukcji tabeli Create / Alter?

— AngryHacker

Klucz kandydacki to kolejny klucz kwalifikujący się do otrzymania klucza podstawowego. Na przykład identyfikator jest kluczem podstawowym. Ale w tej samej tabeli, jeśli inna kolumna dla np. PERSON_ID może także jednoznacznie identyfikować wiersz, który nazywa się Kluczem kandydującym. Druga i trzecia reguła normalizacyjna powinny również obowiązywać wszystkie klucze kandydatów.

— srini.venigalla,

Zrozumiany. Co z drugą częścią mojego pytania?

— AngryHacker

Taki sam jak każdy inny indeks. przykład: UTWÓRZ INDEKS IX_ProductVendor_VendorID ON Purchasing.ProductVendor (BusinessEntityID);

— srini.venigalla,

To jest absolutnie niepoprawne. Możesz podzielić na wiele pól, które w ogóle nie są związane z PK, np OrderDate. Czy masz coś na poparcie swoich roszczeń?

— JNK,