¿Qué atributos están disponibles para usted? ¿De qué le importa su aplicación? Por ejemplo, no pueden nacer dos personas exactamente en el mismo segundo en exactamente el mismo lugar, ¡pero es probable que no tenga acceso a esos datos con ese nivel de precisión! Por lo tanto, debe decidir, a partir de los atributos que tiene intención de modelar, cuáles son suficientes para proporcionar un nivel aceptable de integridad de datos. Elija lo que elija, tiene razón al centrarse en los aspectos de integridad de los datos (evitando la inserción de múltiples filas para la misma persona) de su selección.
Para uniones/Llaves externas en otras tablas, es mejor utilizar una llave sustituta.
He llegado a considerar el uso de la palabra Clave principal como un nombre inapropiado, o en el mejor de los casos, confuso. Cualquier tecla, si se marca como clave principal, alternativo clave, clave única, o índice único, sigue siendo una clave, y requiere que cada fila de la tabla contiene valores únicos de los atributos de la llave. En ese sentido, todas las claves son equivalentes. Lo que importa más (la mayoría) es si son claves naturales (dependientes de atributos de datos de modelo de dominio real significativos) o sustitutos (Independendant de atributos de datos reales)
En segundo lugar, lo que también importa es para qué usa la clave Las claves sustitutas son simples y estrechas y nunca cambian (no hay razón para que no signifiquen nada). Por lo tanto, son una mejor opción para combinaciones o claves externas en otras tablas dependientes.
Pero para garantizar la integridad de los datos y evitar la inserción de múltiples filas para la misma entidad de dominio, son totalmente inútiles ... Para eso necesita algún tipo de clave natural, elegida entre los datos que tiene disponibles, y que tu aplicación está modelando para algún propósito.
La clave no tiene que ser 100% inmutable. Si (por ejemplo) usa Nombre y Número de teléfono y Fecha de nacimiento, por ejemplo, incluso si una persona cambia su nombre o su número de teléfono, simplemente puede cambiar el valor en la tabla. Mientras que ninguna otra fila ya tenga los nuevos valores en sus atributos clave, usted está bien.
Incluso si la tecla que seleccionas solo funciona en el 99.9% de los casos, (digamos que tienes la mala suerte de toparte con dos personas con el mismo nombre y número de teléfono y que casualmente nacieron el mismo día), bueno, al menos Se garantizará que el 99.9% de sus datos sean precisos y consistentes, y puede, por ejemplo, agregar tiempo a su fecha de nacimiento para hacerlos únicos o agregar algún otro atributo a la clave para distinguirlos. Siempre que no tenga que actualizar los valores de los datos en las claves externas en su base de datos debido al cambio (ya que no está utilizando esta clave como un FK en otro lugar) no enfrentará ningún problema importante.
En Oracle PL/SQL le brinda la capacidad de mantener la exclusividad del nivel de la base de datos, ya que puede escribir código sql para manipular la lógica comercial. De hecho, todos los demás dialectos de T-SQL te otorgan ese poder hasta donde yo sé. Sin embargo, este no es un comportamiento estándar para todos los motores sql. La singularidad parece ser un problema de lógica de negocios en sus requisitos. Así que ve por eso en la aplicación. – user114285