Jaka jest różnica między kluczem podstawowym a ograniczeniem klucza niepowtarzalnego?

Question

Jaka jest różnica między Primary key i unique Key constraint?

Jaki jest tego pożytek?

Answer 1

Obie są używane do oznaczenia candidate keys dla tabeli.

Możesz mieć tylko jeden klucz podstawowy dla tabeli, więc wystarczy wybrać jeden, jeśli masz wielu kandydatów.

Obie mogą być używane w ograniczeniach klucza obcego. W SQL Server kolumny klucza głównego nie mogą być zerowane. Kolumny używane w ograniczeniach klucza unikatowego mogą być.

Domyślnie w SQL Server klucz podstawowy staje się indeksem klastrowym, jeśli jest tworzony na stercie, ale nie jest to bezwzględnie obowiązkowe, aby indeks PK i indeks klastrowany były takie same.

Answer 2

klucz podstawowy:

1. Klucz podstawowy jest tylko to jednoznacznie identyfikuje każdy wiersz w tabeli.

2. Klucz podstawowy nie zezwala na powielanie wartości ani NULL.

3. Kluczem domyślnym jest domyślnie indeks klastrowy.

4. Tabela może mieć tylko jeden klucz podstawowy.

unikalny klucz:

1. unikalny klucz ma nic, ale to jednoznacznie identyfikuje każdy wiersz w tabeli.

2. Unikalny klucz nie pozwala na powielanie wartości, ale pozwala (maksymalnie jeden) NULL.

3. Klucz unikatowy to domyślnie indeks nieklastrowy.

Jest to owoc pełny link, aby zrozumieć Primary KeyDatabase Keys. Pamiętaj, mamy tylko jednego indeksu klastrowego w tabeli [Rozmowa o SQL Server 2005]. Teraz, jeśli chcemy dodać kolejną unikalną kolumnę, użyjemy kolumny Niepowtarzalny klucz, ponieważ kolumna unikatowego klucza może być dodana więcej niż jeden.

Answer 3

Klucz podstawowy to taki, który służy do identyfikacji danego wiersza. Może również mieć znaczenie poza tym (jeśli był już fragment "prawdziwych" danych, które mogłyby służyć) lub może być czysto artefaktem implementacji (większość kolumn IDENTITY i równoważnymi automatycznie zwiększanymi wartościami w innych systemach baz danych).

Unikalny klucz to bardziej ogólny przypadek, w którym klucz nie może mieć powtarzających się wartości. W większości przypadków ludzie nie mogą mieć takich samych numerów ubezpieczenia społecznego w odniesieniu do tej samej jurysdykcji (sprawa międzynarodowa może się różnić). Gdybyśmy więc przechowywali numery ubezpieczenia społecznego, chcielibyśmy je modelować jako unikalne, ponieważ każdy przypadek dopasowania ich do istniejącego numeru jest wyraźnie błędny. Nazwy użytkowników również muszą być unikatowe, więc tutaj jest inny przypadek. Zewnętrzne identyfikatory (identyfikatory używane przez inny system, standard lub protokół) są również unikatowe, np. istnieje tylko jeden język, który ma dany kod ISO 639, więc gdybyśmy zapisywali kody ISO 639, modelowalibyśmy to jako unikalne.

Ta wyjątkowość może dotyczyć więcej niż jednej kolumny. Na przykład w większości hierarchicznych systemów kategoryzacji (np. Struktura folderów) żaden element nie może mieć tego samego elementu nadrzędnego i tej samej nazwy, chociaż mogą istnieć inne elementy z tymi samymi nadrzędnymi i różnymi nazwami oraz inne o tej samej nazwie i różnych rodzice. Ta funkcja wielokolumnowa występuje również w kluczach podstawowych.

Tabela może mieć także więcej niż jeden unikalny klucz. Na przykład. użytkownik może mieć zarówno numer identyfikacyjny, jak i nazwę użytkownika, a oba muszą być unikatowe.

Dowolny nieululowany klucz unikalny może w związku z tym służyć jako klucz podstawowy. Czasami klucze podstawowe pochodzące z modelowanych danych wrodzonych są nazywane "naturalnymi kluczami podstawowymi", ponieważ są "naturalną" częścią danych, a nie tylko artefaktem implementacji. Decyzja co do używania zależy od kilku czynników:

1. Prawdopodobieństwo zmiany specyfikacji. Jeśli modelujemy numer ubezpieczenia społecznego jako unikatowy, a następnie musieliśmy się dostosować, aby umożliwić wiele jurysdykcji, w których dwa lub więcej używają podobnego dostatecznego systemu numerowania, aby umożliwić kolizje, najprawdopodobniej musimy po prostu usunąć ograniczenie unikalności (inne zmiany mogą wymagać innych modyfikacji).). Jeśli był to nasz klucz podstawowy, musimy teraz użyć nowego klucza podstawowego i zmienić dowolną tabelę, która używała tego klucza podstawowego jako część relacji, oraz każde zapytanie, które dołączyło do niego.

2. Prędkość wyszukiwania. Kluczowa wydajność może być ważna, ponieważ są one używane w wielu klauzulach WHERE i (częściej) w wielu JOIN s. W szczególności z JOINS, szybkość wyszukiwania może być istotna. Wpływ będzie zależał od szczegółów implementacji, a różne bazy danych będą się różnić w zależności od tego, w jaki sposób będą obsługiwać różne typy danych (miałbym kilka wad z perspektywy wydajności, używając dużego fragmentu tekstu jako klucza głównego w Postgres, gdzie mogłem określić użycie hash dołącza, ale byłbym bardzo niezdecydowany to zrobić w SQLServer [Edit: for "large" Myślę o wielkości nazwy użytkownika, a nie o wielkości całego Norse Eddas!]).

3. Częstotliwość klucza to jedyne interesujące dane. Na przykład, przy tabeli języków i tabeli fragmentów komentarzy w tym języku, bardzo często jedynym powodem, dla którego chciałbym dołączyć do tabeli językowej podczas pracy z tabelą komentarzy, jest uzyskanie kodu języka lub ograniczenie zapytanie do osób z określonym kodem języka. Inne informacje na temat tego języka mogą być znacznie rzadziej stosowane. W tym przypadku łączenie przy kodzie prawdopodobnie będzie mniej skuteczne niż dołączanie do zestawu liczbowego identyfikatora z kolumny IDENTITY, z kodem jako kluczem podstawowym - a więc tym, co jest przechowywane w kolumnie klucza obcego w tabeli komentarzy. w ogóle usunie potrzebę jakiegokolwiek JOIN ze znacznym wzrostem wydajności. Częściej jednak potrzebuję więcej informacji z odpowiednich tabel niż to, więc ważniejsze jest sprawienie, aby JOIN był bardziej wydajny.

Answer 4

Krótka wersja:

• Z punktu widzenia teorii baz danych, nie ma. Oba są po prostu kluczami kandydującymi.
• W praktyce większość DMBS lubi mieć jeden "standardowy klucz", który może być użyty np. decydowanie o tym, jak przechowywać dane, oraz o narzędziach i klientach baz danych, które są najlepszym sposobem identyfikacji rekordu.

Wyróżnienie jednego klucza unikalnego jako "klucza podstawowego" jest po prostu wygodą wdrożenia (ale ważnym).

Answer 5

Kluczem podstawowym jest tylko jeden klucz kandydujący. Zasadniczo klucze podstawowe nie różnią się od innych kluczy kandydujących, ponieważ wszystkie klucze są równe w modelu relacyjnym.

SQL ma jednak dwie różne składnie do implementacji kluczy kandydujących: ograniczenie PRIMARY KEY i ograniczenie UNIQUE (oczywiście w przypadku kolumn nie-nullable). W praktyce osiągają dokładnie to samo, z wyjątkiem zasadniczo bezużytecznego ograniczenia, że ​​KLUCZ GŁÓWNY może być użyty tylko raz na tabelę, podczas gdy ograniczenie UNIQUE może być używane wiele razy.

Tak więc nie ma podstawowego "użycia" dla ograniczenia klucza PRIMARY. Jest zbędny i można go łatwo zignorować lub całkowicie z niego zrezygnować. Jednak wiele osób uważa, że ​​wygodnie jest wyróżnić jeden konkretny klucz na stół jako mający szczególne znaczenie. Istnieje bardzo powszechnie stosowana konwencja, że ​​klucze oznaczone KLAWCEM PODSTAWOWYM są używane dla kluczy obcych, chociaż jest to całkowicie opcjonalne.

Answer 6

Zarówno klucz podstawowy, jak i klucz unikalny służą do wymuszenia niepowtarzalności kolumny. A więc kiedy wybierasz jeden nad drugim?

Tabela może zawierać tylko jeden klucz podstawowy. Jeśli chcesz wymusić unikalność na 2 lub więcej kolumnach, użyjemy ograniczenia klucza unikatowego.

Różnica między ograniczeniem klucza podstawowego a ograniczeniem klucza unikatowego?

1. Stół może mieć tylko jeden klucz podstawowy, ale więcej niż jeden unikalny klucz

2. Klucz podstawowy nie dopuszcza wartości null, gdzie jako unikalny klucz pozwala zerowej

ALTER TABLE Table_Name 
ADD CONSTRAINT Constraint_Name PRIMARY KEY (Column_Name) 

Alter Table Table_Name 
Add Constraint Constraint_Name Unique(Column_Name)