¿Usar la dirección de correo electrónico como clave principal?

¿Es la dirección de correo electrónico un mal candidato para la primaria en comparación con los números de incremento automático?

Nuestra aplicación web necesita que la dirección de correo electrónico sea única en el sistema. Entonces, pensé en usar la dirección de correo electrónico como clave principal. Sin embargo, mi colega sugiere que la comparación de cadenas será más lenta que la comparación de enteros.

¿Es una razón válida para no usar el correo electrónico como clave principal?

Estamos utilizando PostgreSQL.

La comparación de cadenas es más lenta que la comparación int. Sin embargo, esto no importa si simplemente recupera un usuario de la base de datos utilizando la dirección de correo electrónico. Importa si tiene consultas complejas con múltiples combinaciones.

Si almacena información sobre usuarios en varias tablas, las claves externas para la tabla de usuarios serán la dirección de correo electrónico. Eso significa que almacena la dirección de correo electrónico varias veces.

También señalaré que el correo electrónico es una mala elección para hacer un campo único, hay personas e incluso pequeñas empresas que comparten una dirección de correo electrónico. Y al igual que los números de teléfono, los correos electrónicos pueden reutilizarse. [email protected] puede pertenecer fácilmente a John Smith un año y a Julia Smith dos años después.

Otro problema con los correos electrónicos es que cambian con frecuencia. Si se está uniendo a otras tablas con eso como la clave, también deberá actualizar las otras tablas, lo que puede ser un gran éxito cuando una empresa cliente completa cambia sus correos electrónicos (lo que he visto suceder).

la clave primaria debe ser única y constante

Las direcciones de correo electrónico cambian como las estaciones. Útil como una clave secundaria para la búsqueda, pero una mala elección para la clave primaria.

Desventajas de usar una dirección de correo electrónico como clave principal:

1. Más lento al hacer uniones.

2. Cualquier otro registro con una clave externa publicada ahora tiene un valor mayor, ocupando más espacio en disco. (Dado el costo del espacio en disco hoy en día, este es probablemente un problema trivial, excepto en la medida en que el registro ahora demore más en leerse. Ver # 1).

3. Una dirección de correo electrónico podría cambiar, lo que obliga a actualizar todos los registros que lo utilizan como clave externa. Como la dirección de correo electrónico no cambia con tanta frecuencia, el problema de rendimiento es probablemente menor. El mayor problema es que debes asegurarte de proveerlo. Si tiene que escribir el código, esto es más trabajo e introduce la posibilidad de errores. Si su motor de base de datos admite "en cascada de actualizaciones", es un problema menor.

Ventajas de usar la dirección de correo electrónico como clave principal:

1. Es posible que pueda eliminar por completo algunas uniones. Si todo lo que necesita del "registro maestro" es la dirección de correo electrónico, entonces con una clave entera abstracta, tendría que hacer una unión para recuperarlo. Si la clave es la dirección de correo electrónico, entonces ya la tiene y la unión es innecesaria. Si esto le ayuda en algo depende de la frecuencia con la que surja esta situación.

2. Cuando realiza consultas ad hoc, es fácil para un ser humano ver a qué registro maestro se hace referencia. Esto puede ser de gran ayuda cuando se trata de rastrear problemas de datos.

3. Es casi seguro que necesitará un índice en la dirección de correo electrónico de todos modos, por lo que al ser la clave principal se elimina un índice, lo que mejora el rendimiento de las inserciones, ya que ahora solo tienen un índice para actualizar en lugar de dos.

En mi humilde opinión, no es un slam-dunk de ninguna manera. Tiendo a preferir el uso de claves naturales cuando hay una práctica disponible porque son más fáciles de trabajar y las desventajas tienden a no importar mucho en la mayoría de los casos.

Es bastante malo Suponga que algún proveedor de correo electrónico cierra. Los usuarios querrán cambiar su correo electrónico. Si ha utilizado el correo electrónico como clave principal, todas las claves externas para los usuarios duplicarán ese correo electrónico, lo que hace que sea muy difícil de cambiar ...

... y ni siquiera he comenzado a hablar sobre consideraciones de rendimiento.

No sé si eso podría ser un problema en su configuración, pero dependiendo de su RDBMS, los valores de una columna pueden ser sensibles a mayúsculas y minúsculas . Los documentos de PostgreSQL dicen: "Si declara una columna como ÚNICA o CLAVE PRIMARIA, el índice generado implícitamente distingue entre mayúsculas y minúsculas". En otras palabras, si acepta la entrada del usuario para una búsqueda en una tabla con el correo electrónico como clave principal y el usuario proporciona "[email protected]", no encontrará "[email protected]".

Nadie parece haber mencionado un posible problema de que las direcciones de correo electrónico puedan considerarse privadas. Si la dirección de correo electrónico es la clave principal, lo más probable es que la URL de una página de perfil tenga un aspecto similar ..../Users/[email protected]. ¿Qué sucede si no desea exponer la dirección de correo electrónico del usuario? Tendría que encontrar otra forma de identificar al usuario, posiblemente mediante un valor entero único para hacer que las URL sean similares ..../Users/1. Entonces terminarías con un valor entero único después de todo.

En el nivel lógico , el correo electrónico es la clave natural. En el nivel físico , dado que está utilizando una base de datos relacional, la clave natural no encaja bien como clave principal. La razón es principalmente los problemas de rendimiento mencionados por otros.

Por esa razón, el diseño se puede adaptar. La clave natural se convierte en la clave alternativa (ÚNICA, NO NULA), y utiliza una clave sustituta / artificial / técnica como clave principal, que puede ser un incremento automático en su caso.

systemmpuntoout preguntó,

¿Qué pasa si alguien quiere cambiar su dirección de correo electrónico? ¿Vas a cambiar todas las claves foráneas también?

Para eso es en cascada .

Otra razón para usar una clave sustituta numérica como clave principal está relacionada con el funcionamiento de la indexación en su plataforma. En InnoDB de MySQL, por ejemplo, todos los índices de una tabla tienen la clave principal preestablecida, por lo que desea que la PK sea lo más pequeña posible (por razones de velocidad y tamaño). También relacionado con esto, InnoDB es más rápido cuando la clave primaria se almacena en secuencia, y una cadena no ayudaría allí.

Otra cosa a tener en cuenta al usar una cadena como una clave alternativa es que usar un hash de la cadena real que desea puede ser más rápido, omitiendo elementos como mayúsculas y minúsculas de algunas letras. (De hecho, aterricé aquí mientras buscaba una referencia para confirmar lo que acabo de decir; todavía busco ...)

Sí, es una clave primaria incorrecta porque sus usuarios querrán actualizar sus direcciones de correo electrónico.

sí, es mejor si usas un entero en su lugar. También puede configurar su columna de correo electrónico como restricción única.

Me gusta esto:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

Otra razón por la cual la clave primaria entera es mejor es cuando se refiere a la dirección de correo electrónico en una tabla diferente. Si la dirección en sí es una clave principal, en otra tabla debe usarla como clave. Así que almacenas direcciones de correo electrónico varias veces.

No estoy muy familiarizado con los postgres. Primary Keys es un gran tema. He visto algunas excelentes preguntas y respuestas en este sitio (stackoverflow.com).

Creo que puede tener un mejor rendimiento al tener una clave primaria numérica y usar un ÍNDICE ÚNICO en la columna de correo electrónico. Los correos electrónicos tienden a variar en longitud y pueden no ser adecuados para el índice de clave principal.

Un poco de lectura aquí y aquí.

Personalmente, no utilizo ninguna información para la clave principal cuando diseño la base de datos, porque es muy probable que necesite modificar cualquier información más adelante. La única razón por la que proporciono la clave primaria es que es conveniente realizar la mayoría de las operaciones de SQL desde el lado del cliente, y mi elección para eso siempre ha sido el tipo entero de incremento automático.

Su colega tiene razón: use un entero de incremento automático para su clave principal.

Puede implementar la unicidad del correo electrónico a nivel de aplicación, o puede marcar su columna de dirección de correo electrónico como única y agregar un índice en esa columna.

Agregar el campo como único le costará la comparación de cadenas solo cuando se inserte en esa tabla, y no cuando realice uniones y comprobaciones de restricciones de clave externa.

Por supuesto, debe tener en cuenta que agregar restricciones a su aplicación a nivel de base de datos puede hacer que su aplicación se vuelva inflexible. Siempre preste la debida consideración antes de hacer cualquier campo "único" o "no nulo" solo porque su aplicación necesita que sea único o no esté vacío.

Use un GUID como clave principal ... de esa manera puede generarlo desde su programa cuando hace un INSERT y no necesita obtener una respuesta del servidor para averiguar cuál es la clave primaria. También será único en todas las tablas y bases de datos y no tendrá que preocuparse por lo que suceda si trunca la tabla algún día y el incremento automático se restablece a 1.

Sé que esta entrada es un poco tardía, pero me gustaría agregar que las personas abandonan las cuentas de correo electrónico y los proveedores de servicios recuperan la dirección permitiendo que otra persona la use.

Como señaló @HLGEM "[email protected] puede pertenecer fácilmente a John Smith un año y a Julia Smith dos años después". en este caso, si John Smith quiere su servicio, debe negarse a usar su dirección de correo electrónico o eliminar todos sus registros relacionados con Julia Smith.

Si tiene que eliminar registros y se relacionan con el historial financiero de la empresa, según la ley local, podría encontrarse en apuros.

Por lo tanto, nunca usaría datos como direcciones de correo electrónico, placas de matrícula, etc., como claves principales, porque no importa cuán únicos parezcan estar fuera de su control y pueden proporcionar algunos desafíos interesantes con los que puede que no tenga tiempo para lidiar.

Es posible que deba considerar cualquier legislación de regulación de datos aplicable. El correo electrónico es información personal, y si sus usuarios son ciudadanos de la UE, por ejemplo, bajo GDPR pueden indicarle que elimine su información de sus registros (recuerde que esto se aplica independientemente del país en el que se encuentre).

Si necesita mantener el registro en la base de datos por integridad referencial o por razones históricas como la auditoría, el uso de una clave sustituta le permitiría simplemente NULAR todos los campos de datos personales. Obviamente, esto no es tan fácil si sus datos personales son la clave principal

puede aumentar el rendimiento utilizando la clave primaria entera.

debes usar una clave primaria entera. Si necesita que la columna de correo electrónico sea única, ¿por qué no establece simplemente un índice único en esa columna?

Si tiene un valor no int como clave principal, las inserciones y recuperaciones serán muy lentas en datos grandes.

La clave primaria debe elegirse como un atributo estático. Dado que las direcciones de correo electrónico no son estáticas y pueden ser compartidas por múltiples candidatos, no es una buena idea usarlas como clave principal. Además, las direcciones de correo electrónico son cadenas de una cierta longitud que pueden ser mayores que la identificación única que nos gustaría usar [len (dirección_de_email)> len (id_unica)] por lo que requeriría más espacio e incluso peor, se almacenan varias veces como clave externa . Y, en consecuencia, conducirá a degradar el rendimiento.

Depende de la mesa. Si las filas en su tabla representan direcciones de correo electrónico, entonces el correo electrónico es la mejor identificación. Si no, entonces el correo electrónico no es una buena identificación.

Si se trata simplemente de exigir que el correo electrónico sea único, puede crear un índice único con esa columna.

El correo electrónico es un buen candidato de índice único, pero no para la clave principal, si es una clave principal, no podrá cambiar la dirección de correo electrónico del contacto, por ejemplo. Creo que sus consultas de unión también serán más lentas.

no use la dirección de correo electrónico como clave principal, mantenga el correo electrónico como único pero no lo use como clave principal, use la identificación de usuario o el nombre de usuario como clave principal