Como prefacio, tenga en cuenta que una clave principal no necesita ser una sola columna:puede estar compuesta por varias columnas:esto se conoce como clave compuesta. También tenga en cuenta que no todas las tablas tienen un AUTO_INCREMENT /IDENTITY columna, y puede tener un UNIQUE restricción en una sola columna dentro de una clave compuesta de todos modos.
-
No hay ninguno, pero no tiene sentido que un DBMS prohiba tal redundancia porque necesitaría lógica y complejidad adicionales para manejar esa condición, mientras que no hay ningún daño real al tener ambos (además del impacto en el rendimiento de tener que mantener dos índices).
-
Como se dijo anteriormente:porque el coste de oportunidad de detectar y prevenir esa redundancia no vale la pena.
Otra cosa a considerar es que la definición de clave principal de una tabla no es inmutable y, por lo tanto, está sujeta a cambios. Es posible que una tabla ya tenga columnas con un UNIQUE configuración de la restricción y luego el diseñador de la base de datos decide incluir eso en una nueva definición de la clave principal:no sería fácil para el usuario solicitar que se elimine primero la restricción anterior, especialmente si otras partes de su sistema de aplicación dependen de esa restricción ÚNICA está allí (por ejemplo, un 1:0..1 definición de relación).
(También, AUTO_INCREMENT no es mutuamente inclusivo con UNIQUE o PRIMARY KEY :puedes usar AUTO_INCREMENT con columnas no únicas (por ejemplo, si AUTO_INCREMENT se agrega después de que una tabla ya contiene datos) y, por el contrario, una PRIMARY KEY puede usar valores únicos obtenidos de otros lugares, como otra columna de identidad como clave externa (¡las claves primarias compuestas pueden contener claves externas!) o una fuente de datos "natural", como usar un número de seguro social de EE. deberías nunca hacer esto en realidad)).
