¿Está bien tener clave externa como clave principal?

Tengo la tabla “Usuario” (nombre de usuario, contraseña) y la tabla “Perfil” (ID de perfil, género, fecha de nacimiento, …). Actualmente estoy usando este enfoque: cada registro de perfil tiene un campo llamado “userId” como clave externa que se vincula a la tabla de usuario. Cuando un usuario se registra, su registro de Perfil se crea automáticamente. Estoy confundido con la sugerencia de mi amigo: tener el campo “userId” como la clave externa y principal y eliminar el campo “profileId”. ¿Qué enfoque es mejor?

Las claves externas casi siempre son “Permitir duplicados”, lo que las haría inadecuadas como claves primarias.

En su lugar, busque un campo que identifique de manera única cada registro en la tabla, o agregue un nuevo campo (ya sea un entero de incremento automático o un GUID) para actuar como clave principal.

La única excepción a esto son las tablas con una relación de uno a uno, donde la clave externa y la clave principal de la tabla vinculada son una y la misma.

Las claves primarias siempre deben ser únicas, las claves externas deben permitir valores no exclusivos si la tabla es una relación de uno a varios. Está perfectamente bien utilizar una clave externa como clave principal si la tabla está conectada por una relación uno a uno, no una relación de uno a muchos. Si desea que el mismo registro de usuario tenga la posibilidad de tener más de 1 registro de perfil relacionado, vaya con una clave principal separada, de lo contrario, quédese con lo que tiene.

En general, se considera una mala práctica tener una relación uno a uno. Esto se debe a que solo podría tener los datos representados en una tabla y lograr el mismo resultado.

Sin embargo, hay casos en los que es posible que no pueda realizar estos cambios en la tabla a la que hace referencia. En este caso, no hay ningún problema al utilizar la clave Extranjera como clave principal. Podría ser útil tener una clave compuesta que consista en una clave primaria única de incremento automático y la clave externa.

Actualmente estoy trabajando en un sistema donde los usuarios pueden iniciar sesión y generar un código de registro para usar con una aplicación. Por razones que no entraré, no puedo simplemente agregar las columnas requeridas a la tabla de usuarios. Así que voy por una ruta de uno a uno con la tabla de códigos.

Sí, una clave externa puede ser una clave principal en el caso de una relación uno a uno entre esas tablas

Yo no haría eso. Mantendría el profileID como clave principal de la tabla Profile

Una clave foránea es solo una restricción referencial entre dos tablas

Se podría argumentar que una clave primaria es necesaria como el objective de cualquier clave externa que se refiera a ella desde otras tablas. Una clave externa es un conjunto de una o más columnas en cualquier tabla (no necesariamente una clave candidata, y menos la clave principal, de esa tabla) que puede contener los valores encontrados en la (s) columna (s) de clave principal de algunos otra mesa Entonces, debemos tener una clave primaria para que coincida con la clave externa. ¿O debemos? El único propósito de la clave primaria en la clave primaria / par de claves foráneas es proporcionar una combinación inequívoca: para mantener la integridad referencial con respecto a la tabla “extranjera” que contiene la clave primaria referenciada. Esto asegura que el valor al que se refiere la clave externa siempre será válido (o nulo, si está permitido).

http://www.aisintl.com/case/primary_and_foreign_key.html

Depende del negocio y el sistema.

Si su userId es único y será único todo el tiempo, puede usar userId como su clave principal. Pero si alguna vez quiere expandir su sistema, hará las cosas difíciles. Le aconsejo que agregue una clave externa en el usuario de la tabla para establecer una relación con el perfil de la tabla en lugar de agregar una clave externa en el perfil de la tabla.

Sí, es legal tener una clave principal como clave externa. Este es un constructo raro, pero se aplica para:

  • una relación 1: 1. Las dos tablas no se pueden fusionar en una debido a los diferentes permisos y privilegios que solo se aplican a nivel de tabla (a partir de 2017, una base de datos así sería impar).

  • una relación 1: 0..1. El perfil puede existir o no, según el tipo de usuario.

  • el rendimiento es un problema, y ​​el diseño actúa como una partición: raramente se accede a la tabla de perfiles, se aloja en un disco separado o tiene una política de fragmentación diferente en comparación con la tabla de usuarios. No tendría sentido si el almacenamiento de subrayado es columnar.