Czy jest jakaś korzyść z klucza podstawowego, który obejmuje wszystkie kolumny tabeli?

Mam tabelę z czterema kolumnami, których wszystkie nie są wartościami zerowymi, a dane są takie, że wszystkie cztery są potrzebne do odróżnienia unikalnego rekordu. Oznacza to, że gdybym utworzył klucz podstawowy, musiałby on zawierać wszystkie kolumny. Zapytania do tabeli prawie zawsze będą polegały na wyciągnięciu jednego rekordu, tzn. Wszystkie kolumny zostaną przefiltrowane w zapytaniu.

Ponieważ każda kolumna będzie musiała zostać przeszukana, czy posiadanie klucza podstawowego w ogóle mi się przydaje (oprócz wymuszania unikalności rekordów)?

W twoim przypadku pola te są kluczem naturalnym .

Klucz zastępczy:

Klucze zastępcze to klucze, które nie mają znaczenia „biznesowego” i służą wyłącznie do identyfikacji rekordu w tabeli. Takie klucze są generowane w bazie danych (przykład: Tożsamość w SQL Server, Sekwencja w Oracle, Sekwencja / Tożsamość w DB2 UDB itp.) Lub wartości generowane przez system (jak generowane za pomocą tabeli w schemacie).

Naturalny klucz:

Klucze są naturalne, jeśli reprezentowany przez nie atrybut służy do identyfikacji niezależnie od schematu bazy danych. Zasadniczo oznacza to, że klucze są naturalne, jeśli ludzie używają ich na przykład: numery faktur, numery podatkowe, SSN itp.

Klucze zastępcze a klucze naturalne dla klucza podstawowego

Wolę dodać klucz zastępczy do oddzielnego zarządzania modelami biznesowymi i bazami danych. Innym pytaniem jest użycie indeksu klastrowanego i nieklastrowanego na kluczu podstawowym. Jeśli zmienisz tabelę (tabela niestatyczna, ma ona intensywne wstawianie lub aktualizację), wystąpi problem z wydajnością w przypadku użycia indeksu klastrowego na niemonotonicznym kluczu podwyższonym.

Zazwyczaj zaleca się posiadanie klucza zastępczego w takich sytuacjach, więc klucze obce w innych tabelach (i wszelkie odniesienia do rekordów, które mogą być przechowywane zewnętrznie, na przykład jeśli są one przenoszone na ciągi zapytań, w których żądanie http (s) odnosi się do jednego rekordów) mają coś do odniesienia, co nie zmieni się, jeśli zmienią się dane w wierszu. Jeśli to zrobisz, będzie to Twój klucz podstawowy.

Jeśli nie dodasz takiego klucza zastępczego, biorąc pod uwagę, jak opisujesz dostęp do danych, mając wszystkie cztery kolumny jako klucz podstawowy, nie będzie to niekorzystne. Jeśli uczynisz klucz indeksem klastrowym dla tabeli, pomoże to takim żądaniom, ponieważ będzie jeden poziom w b-drzewie na dysku, aby przejść w dół, aby znaleźć dane dla danego wiersza.

Klucze złożone jako klucze podstawowe również napotykają problemy z rozmiarem indeksu, które mogą wpływać na użycie dysku, prędkości io i kopie zapasowe. Możesz przejrzeć posty Kimberly Tripp na temat kluczy podstawowych i indeksów klastrowych tutaj: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

Ja również sugerowałbym klucz zastępczy w tym przypadku zamiast klucza naturalnego.

Jeśli masz tabelę reprezentującą relację wiele do wielu, która ma tylko 2 kolumny, wydaje się to rozsądne.

Por. to SO pytanie

Przyznaję jednak, że dodam klucze zastępcze nawet w tych przypadkach.