¿Crear ID de usuario aunque los nombres de usuario sean únicos?

Mi aplicación web tendrá varios tipos de usuarios: un usuario raíz, administradores de sistemas, clientes, contratistas, etc. Me gustaría tener una tabla “Usuario” que tendrá las columnas “Nombre de usuario”, “Contraseña” y ” Papel “con el rol que es uno de los roles antes mencionados. Por ejemplo, también tendré una tabla llamada “Cliente” para almacenar atributos específicos del cliente.

Aquí está mi pregunta Como todos los nombres de usuario serán únicos, podría usar el nombre de usuario como clave principal para la tabla de Usuario. ¿Tendría más sentido, sin embargo, crear una columna de “ID de usuario” y usarla en lugar de la columna Nombre de usuario como PK? Hay muchas otras tablas que utilizarán esta PK de usuario como clave externa y creo que, desde el punto de vista del rendimiento, será más rápido comparar las ID de usuario que las cadenas de texto de nombre de usuario.

Gracias por su respuesta.

Crearía el ID de usuario porque, aunque los nombres de usuario pueden ser únicos, en general no son intercambiables y preferiría no tener que cambiar miles o millones de registros porque HLGEM quería convertirse en HLGEM_1. Las uniones adicionales en enteros son más rápidas.

Este es el viejo debate clave natural versus sustituto.

En pocas palabras, nada es cortante y tendrá que equilibrar entre intereses en competencia:

  1. Si anticipa que deberá actualizar la clave, use el sustituto (que no necesita actualización) para evitar ON ACTUALIZAR CASCADE.
  2. Si necesita buscar la clave, pero no las otras columnas , use la tecla natural para evitar el JOIN por completo. Pero si necesita buscar más que solo la clave, utilice un sustituto para hacer FK y los índices que lo acompañan más delgados y más eficientes.
  3. ¿Anticipa escaneos de rango en la clave natural? En caso afirmativo, agrúpelo . Sin embargo, los índices secundarios pueden ser costosos en tablas agrupadas, que juegan contra una clave sustituta.
  4. ¿Tu mesa es muy grande? Ahorre espacio teniendo solo un índice (en clave natural) en lugar de dos (en natural y sustituto).
  5. Las claves naturales compuestas (que se encuentran en los puntos finales secundarios de las relaciones de identificación) pueden ser necesarias para modelar correctamente las dependencias en forma de diamante .
  6. Los sustitutos pueden ser más amigables con las herramientas de ORM.

En el caso de los nombres de usuario …

  1. Probablemente quieras permitir la actualización.
  2. Es poco probable que necesite buscar solo el nombre de usuario.
  3. Los escaneos de rango en los nombres de usuario no tienen sentido (a diferencia de las búsquedas equies).
  4. No estás almacenando a toda la población de la Tierra, ¿verdad?
  5. Aquí estamos hablando de la clave natural “independiente”, no de una clave natural que es el resultado de una relación de identificación.
  6. ¿Desconocido?

… por lo que la clave sustituta probablemente esté justificada en este caso.

Hay dos escuelas de pensamiento. Los puristas de la base de datos creen que siempre debe usar claves naturales siempre que sea posible (y tiene sentido). Entonces, si se suscribe a esa línea de pensamiento y el nombre de usuario no se puede cambiar, entonces convierta la clave en el nombre de usuario.

Los pragmáticos de bases de datos creen que las claves indirectas son más útiles y tienden a resistir mejor los cambios en los requisitos. También pueden ser más rápidos en algunos casos, especialmente con teclas de cadena grandes. También existen problemas de seguridad, en el sentido de que al usar claves naturales, puede filtrar información que no estaría disponible en una clave sustituta.