Som ett förord, notera att en primärnyckel inte behöver vara en enda kolumn:den kan bestå av flera kolumner:detta kallas en sammansatt nyckel. Observera också att inte alla tabeller har en AUTO_INCREMENT /IDENTITY kolumn alls, och du kan ha en UNIQUE begränsning på en enda kolumn inuti en sammansatt nyckel ändå.
-
Det finns ingen - men det är inte meningsfullt för ett DBMS att förbjuda sådan redundans antingen för att du skulle behöva extra logik och komplexitet för att hantera det tillståndet, medan det inte görs någon verklig skada av att ha båda (förutom prestandaeffekten av att behöva underhålla två index).
-
Som sagt ovan:eftersom möjlighetskostnaden att upptäcka och förhindra att redundans inte är värt det.
En annan sak att tänka på är att den primära nyckeldefinitionen av en tabell inte är oföränderlig och därför kan ändras. En tabell kan redan ha kolumner med en UNIQUE begränsningsinställning och sedan beslutar databasdesignern att inkludera det i en ny definition av primärnyckeln - det skulle vara användarovänligt att kräva att den gamla begränsningen tas bort först, speciellt om andra delar av deras applikationssystem är beroende av att den UNIKA begränsningen finns där (t.ex. en 1:0..1 relationsdefinition).
(Även AUTO_INCREMENT är inte ömsesidigt inkluderande med UNIQUE eller PRIMARY KEY :du kan använda AUTO_INCREMENT med icke-unika kolumner (t.ex. om AUTO_INCREMENT läggs till efter att en tabell redan innehåller data), och tvärtom en PRIMARY KEY kan använda unika värden som kommer från någon annanstans, till exempel en annan identitetskolumn som en främmande nyckel (sammansatta primärnycklar kan innehålla främmande nycklar!) eller en "naturlig" datakälla, som att använda ett amerikanskt personnummer som en primärnyckel (naturligtvis du borde aldrig gör detta i verkligheten)).