Merk als voorwoord op dat een Primary Key geen enkele kolom hoeft te zijn:deze kan uit meerdere kolommen bestaan:dit staat bekend als een Composite Key. Merk ook op dat niet elke tafel een AUTO_INCREMENT . heeft /IDENTITY kolom helemaal niet, en u kunt een UNIQUE . hebben hoe dan ook een beperking op een enkele kolom binnen een samengestelde sleutel.
-
Er is er geen - maar het heeft geen zin voor een DBMS om te verboden zo'n redundantie, ofwel omdat je extra logica en complexiteit nodig hebt om met die situatie om te gaan, terwijl het geen kwaad kan om beide te hebben (afgezien van de prestatie-impact van het moeten onderhouden van twee indexen).
-
Zoals hierboven gezegd:omdat de opportuniteitskosten van het detecteren en voorkomen van die redundantie is het niet waard.
Een ander ding om te overwegen is dat de primaire-sleuteldefinitie van een tabel niet onveranderlijk is en daarom aan verandering onderhevig is. Een tabel kan al kolommen hebben met een UNIQUE constraint instellen en vervolgens besluit de database-ontwerper om dat op te nemen in een nieuwe definitie van de primaire sleutel - het zou gebruikersonvriendelijk zijn om te eisen dat de oude beperking eerst wordt verwijderd, vooral als andere delen van hun applicatiesysteem afhankelijk zijn van die UNIEKE beperking aanwezig is (bijv. een 1:0..1 relatiedefinitie).
(Ook AUTO_INCREMENT is niet wederzijds inclusief met UNIQUE of PRIMARY KEY :u kunt AUTO_INCREMENT . gebruiken met niet-unieke kolommen (bijv. als AUTO_INCREMENT wordt toegevoegd nadat een tabel al gegevens bevat), en omgekeerd een PRIMARY KEY kan unieke waarden gebruiken die van elders afkomstig zijn, zoals een andere identiteitskolom als externe sleutel (samengestelde primaire sleutels kunnen externe sleutels bevatten!) of een "natuurlijke" gegevensbron, zoals het gebruik van een Amerikaans burgerservicenummer als primaire sleutel (uiteraard je moet nooit doe dit in het echt)).