En guise de préface, notez qu'une clé primaire n'a pas besoin d'être une seule colonne :elle peut être composée de plusieurs colonnes :c'est ce qu'on appelle une clé composite. Notez également que toutes les tables n'ont pas un AUTO_INCREMENT /IDENTITY colonne du tout, et vous pouvez avoir un UNIQUE contrainte sur une seule colonne à l'intérieur d'une clé composite de toute façon.
-
Il n'y en a pas - mais cela n'a pas de sens pour un SGBD d'interdire une telle redondance soit parce que vous auriez besoin d'une logique et d'une complexité supplémentaires pour gérer cette condition, alors qu'il n'y a pas vraiment de mal à avoir les deux (en plus de l'impact sur les performances d'avoir à maintenir deux index).
-
Comme dit plus haut :parce que le coût d'opportunité de détecter et de prévenir cette redondance n'en vaut pas la peine.
Une autre chose à considérer est que la définition de la clé primaire d'une table n'est pas immuable et est donc sujette à changement. Une table peut déjà avoir des colonnes avec un UNIQUE configuration de la contrainte, puis le concepteur de la base de données décide de l'inclure dans une nouvelle définition de la clé primaire - il serait peu convivial d'exiger que l'ancienne contrainte soit supprimée en premier, surtout si d'autres parties de leur système d'application dépendent de cette contrainte UNIQUE étant là (par exemple un 1:0..1 définition de la relation).
(Aussi, AUTO_INCREMENT n'est pas mutuellement inclusif avec UNIQUE ou PRIMARY KEY :vous pouvez utiliser AUTO_INCREMENT avec des colonnes non uniques (par exemple, si AUTO_INCREMENT est ajouté après qu'une table contient déjà des données), et à l'inverse une PRIMARY KEY peut utiliser des valeurs uniques provenant d'ailleurs, comme une autre colonne d'identité comme clé étrangère (les clés primaires composites peuvent contenir des clés étrangères !) ou une source de données "naturelle", comme l'utilisation d'un numéro de sécurité sociale américain comme clé primaire (bien sûr vous ne devriez jamais faites-le en réalité)).
