Po co używać int jako klucza podstawowego tabeli odnośników?

Chcę wiedzieć, dlaczego powinienem używać int jako klucza podstawowego tabeli odnośników zamiast po prostu używać wartości odnośnika jako klucza podstawowego (który w większości przypadków byłby ciągiem).

Rozumiem, że użycie nvarchar (50) zamiast int zużyłoby znacznie więcej miejsca, gdyby było połączone z tabelą z wieloma rekordami.

Z drugiej strony bezpośrednie użycie wartości odnośnika w zasadzie pozwoliłoby nam uniknąć łączenia. Mogę sobie wyobrazić, że byłoby to duże oszczędności, gdyby łączenie było zawsze wymagane (pracujemy nad aplikacją internetową, więc to się liczy).

Jakie są zalety korzystania z klucza podstawowego int (szczególnie dla tabeli odnośników), poza tym, że jest to „standardowa rzecz do zrobienia”?

Odpowiedź na twoje pytanie jest logiczna, a nie fizyczna - wartość, na którą patrzysz, może się zmienić z przyczyn biznesowych. Na przykład, jeśli indeksujesz klientów według adresu e-mail, co stanie się, gdy zmieni się adres e-mail? Oczywiście nie dotyczy to wszystkich twoich tabel odnośników, ale korzyści płynące z robienia tego w taki sam sposób w całej aplikacji są takie, że upraszczają kod. Jeśli wewnętrznie wszystko jest liczbami całkowitymi → relacje liczb całkowitych, jesteś objęty ubezpieczeniem.

Po prostu przeczytaj swój komentarz do Sandy - być może w tym przypadku tak naprawdę chcesz Ograniczenia czekowego , a nie tabeli kluczy obcych / odnośników, np .:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

Uruchom to, a otrzymasz:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

Jest to wydajna metoda o wysokiej wydajności, ale wadą jest oczywiście to, że dodanie nowego smaku oznacza zmianę kodu. Odradzam robienie tego w aplikacji - ponieważ musisz to zrobić w każdej aplikacji, która łączy się z tym DB, jest to najczystszy możliwy projekt, ponieważ istnieje tylko jedna ścieżka kodu do sprawdzania poprawności.

„Bezpośrednie używanie wartości odnośnika” - to trochę sprzeczne z rzeczywistym celem tabeli odnośników. Dlaczego trzymasz taki stół? Jeśli to nie jest wyszukiwanie.
Być może źle zrozumiałem twoje pytanie. Oto definicja tabeli odnośników z msdn

Tablica przeglądowa służy do wyświetlania informacji z jednej tabeli na podstawie wartości pola klucza obcego w innej tabeli. Rozważmy na przykład tabelę zamówień w bazie danych sprzedaży. Każdy rekord w tabeli Zamówienia zawiera identyfikator klienta wskazujący, który klient złożył zamówienie. CustomerID to klucz obcy wskazujący na rekord klienta w tabeli Klienci. Przedstawiając listę zamówień (z tabeli Zamówienia), możesz chcieć wyświetlić rzeczywistą nazwę klienta, w przeciwieństwie do CustomerID. Ponieważ nazwa klientów znajduje się w tabeli klientów i prezentujesz dane z tabeli Zamówienia, musisz utworzyć tabelę wyszukiwania, która przyjmuje wartość CustomerID w rekordzie Zamówienia i używa tej wartości do nawigacji w relacji i zwracania więcej czytelna, nazwa klienta.

Czy potrafisz wyjaśnić cel swojej tabeli odnośników? czy jest używany do przechowywania niektórych danych statycznych, takich jak poniższe, a te rekordy nie są danymi wejściowymi innych rekordów tabel?

Tabela smaku

Orange  
Pista  
Mango

Jeśli powyższa jest twoja sytuacja, to polecam nie używać tabeli odnośników; prawdopodobnie zakoduj te wartości list w twojej aplikacji internetowej. W ten sposób można uniknąć niepotrzebnych zapytań do bazy danych.

Ponieważ kwalifikujesz swoje pytanie słowem „specjalnie dla tabeli odnośników”, odpowiedź jest prawdopodobnie uproszczona do „oszczędza miejsce”.

Myślę, że jeśli usuniesz ten kwalifikator, twoje pytanie brzmi: „Po co używać kluczy zastępczych zamiast kluczy naturalnych?” Napisałem następujące na poparcie kluczy zastępczych:

„Migracja jednej liczby całkowitej zamiast szerszego klucza złożonego ma wiele zalet. Zapewnia niezłą spójność w całym modelu fizycznym, generalnie oszczędzając więcej miejsca niż kosztuje i redukuje operacje we / wy w porównaniu do migrowania kluczy złożonych; szczególnie w dobrze znormalizowany model. Dodatkowo upraszczają zrozumienie modelu i sprzężeń zapytań. ”

W dużej mierze dlatego stało się „standardową rzeczą”. Niefortunnym produktem ubocznym jest to, że ludzie wrzucają klucz zastępczy i nie zastanawiają się, jakie są klucze kandydujące ... Ale teraz wychodzimy poza twoje pytanie :)

Jednym z powodów, dla których zawsze używam jest to, że jeśli ktoś źle wpisał wartość w tabeli odnośników, powiedzmy Oraneg zamiast Orange, zmiana wartości w tabeli odnośników jest znacznie łatwiejsza.

Tabela odnośników z kluczem podstawowym liczby wymaga jedynie zmiany wartości w tabeli odnośników.

Tabela odnośników wykorzystująca wartości jako klucz podstawowy będzie musiała zostać zmieniona w tabeli odnośników i w każdym rekordzie w głównej tabeli, w której została użyta.

Definiując identyfikator, możesz również zagwarantować wyjątkowość. Ale kiedy bierzesz, na przykład e-mail, jako unikalny identyfikator, przenosisz odpowiedzialność za wyjątkowość na niezaufaną trzecią stronę.