Na wstępie zauważ, że klucz podstawowy nie musi być pojedynczą kolumną:może składać się z wielu kolumn:jest to znane jako klucz złożony. Pamiętaj też, że nie każda tabela ma AUTO_INCREMENT /IDENTITY w ogóle kolumna i możesz mieć UNIQUE i tak ograniczenie do pojedynczej kolumny wewnątrz klucza złożonego.
-
Nie ma - ale nie ma sensu, aby DBMS zabronił taka nadmiarowość albo dlatego, że potrzebujesz dodatkowej logiki i złożoności, aby poradzić sobie z tym warunkiem, podczas gdy nie ma żadnej szkody wyrządzonej przez posiadanie obu (oprócz wpływu na wydajność konieczności utrzymywania dwóch indeksów).
-
Jak wspomniano powyżej:ponieważ koszt alternatywny wykrywania i zapobiegania nadmiarowości nie jest tego warte.
Inną rzeczą do rozważenia jest to, że definicja klucza podstawowego tabeli nie jest niezmienna i dlatego może ulec zmianie. Tabela może już zawierać kolumny z oznaczeniem UNIQUE po ustawieniu ograniczeń, a następnie projektant bazy danych decyduje się uwzględnić to w nowej definicji klucza podstawowego - byłoby nieprzyjazne dla użytkownika wymagać, aby najpierw usunięto stare ograniczenie, zwłaszcza jeśli inne części ich systemu aplikacji zależą od to ograniczenie UNIQUE istnieje (np. 1:0..1 definicja relacji).
(Również AUTO_INCREMENT nie wyklucza się wzajemnie z UNIQUE lub PRIMARY KEY :możesz użyć AUTO_INCREMENT z nieunikalnymi kolumnami (np. jeśli AUTO_INCREMENT jest dodawany po tym, jak tabela zawiera już dane) i odwrotnie, PRIMARY KEY może używać unikalnych wartości pochodzących z innych źródeł, takich jak inna kolumna tożsamości jako klucz obcy (złożone klucze podstawowe mogą zawierać klucze obce!) lub „naturalne” źródło danych, takie jak używanie amerykańskiego numeru ubezpieczenia społecznego jako klucza podstawowego (oczywiście powinieneś nigdy zrób to w rzeczywistości)).
