sql - simple - tipos de claves en base de datos
¿Usar la dirección de correo electrónico como clave principal? (24)
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.
¿Es la dirección de correo electrónico un mal candidato para el principal en comparación con los números que se incrementan automáticamente?
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 .
Desventajas de usar una dirección de correo electrónico como clave principal:
Más lento al hacer combinaciones.
Cualquier otro registro con una clave externa publicada ahora tiene un valor mayor, y ocupa más espacio en el disco. (Dado el costo del espacio en disco hoy, este es probablemente un problema trivial, excepto en la medida en que el registro ahora toma más tiempo para leer. Consulte el número 1).
Una dirección de correo electrónico podría cambiar, lo que obliga a que se actualicen todos los registros que usan esto como una 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 tienes que 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 actualización en cascada", es un problema menor.
Ventajas de utilizar la dirección de correo electrónico como clave principal:
Es posible que puedas eliminar completamente algunas uniones. Si todo lo que necesita del "registro maestro" es la dirección de correo electrónico, entonces con una clave de entero abstracta tendría que hacer una unión para recuperarla. Si la clave es la dirección de correo electrónico, entonces ya la tiene y la unión no es necesaria. Si esto te ayuda depende de la frecuencia con la que se presente esta situación.
Cuando realiza consultas ad hoc, es fácil para un ser humano ver a qué registro maestro se está haciendo referencia. Esto puede ser de gran ayuda cuando se trata de localizar problemas de datos.
De todos modos, es casi seguro que necesitará un índice en la dirección de correo electrónico, por lo que convertirla en la clave principal elimina un índice, mejorando así el rendimiento de las inserciones, ya que ahora solo tienen que actualizar un índice en lugar de dos.
En mi humilde opinión, no es un slam-dunk de ninguna manera. Tiendo a usar claves naturales cuando hay una disponible porque es más fácil trabajar con ellas y las desventajas tienden a no importar mucho en la mayoría de los casos.
El correo electrónico es un buen candidato único para el índice, 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 tus consultas de unión serán más lentas también.
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 se ajusta bien como la clave principal. La razón es principalmente los problemas de rendimiento mencionados por otros.
Por ese motivo, el diseño puede ser adaptado. La clave natural se convierte en la clave alternativa (ÚNICA, NO NULA), y usted usa una clave sustituta / artificial / técnica como la clave principal, que puede ser un incremento automático en su caso.
systempuntooutout preguntó,
¿Qué pasa si alguien quiere cambiar su dirección de correo electrónico? ¿Vas a cambiar todas las claves externas también?
Para eso está la cascading .
Otra razón para usar una clave sustituta numérica como la clave principal está relacionada con cómo funciona la indexación en su plataforma. En el InnoDB de MySQL, por ejemplo, todos los índices en una tabla tienen la clave principal pre-pendiente, por lo que desea que el PK sea lo más pequeño posible (por razones de velocidad y tamaño). También relacionado con esto, InnoDB es más rápido cuando la clave principal 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 cosas 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 estoy buscando ...)
Es bastante malo Supongamos que algún proveedor de correo electrónico sale del negocio. Los usuarios querrán entonces 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 empezado a hablar sobre consideraciones de rendimiento.
La clave primaria debe ser única y constante.
Las direcciones de correo electrónico cambian como las estaciones. Útil como clave secundaria para búsqueda, pero una mala elección para la clave principal.
La clave primaria debe ser elegida un atributo estático. Dado que las direcciones de correo electrónico no son estáticas y pueden ser compartidas por varios candidatos, no es una buena idea usarlas como clave principal. Además, las direcciones de correo electrónico son cadenas generalmente de una cierta longitud que puede ser mayor que la identificación única que nos gustaría usar [len (dirección_mail)> len (unique_id)], por lo que requeriría más espacio y, lo que es peor, se almacenan varias veces como clave externa . Y en consecuencia conducirá a degradar el rendimiento.
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. No importa si tiene consultas complejas con varias combinaciones.
Si almacena información sobre usuarios en varias tablas, las claves externas a la tabla de usuarios serán la dirección de correo electrónico. Eso significa que usted almacena la dirección de correo electrónico varias veces.
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 a ..../Users/[email protected] . ¿Qué pasa si no quieres exponer la dirección de correo electrónico del usuario? Tendría que encontrar otra forma de identificar al usuario, posiblemente por un valor entero único para hacer URL como ..../Users/1 . Después de todo, terminarías con un valor entero único.
No estoy muy familiarizado con postgres. Claves primarias es un gran tema. He visto algunas preguntas y respuestas excelentes en este sitio (.com).
Creo que puede tener un mejor rendimiento al tener una clave principal numérica y utilizar 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.
No sé si eso podría ser un problema en su configuración, pero dependiendo de su RDBMS, los valores de una columna pueden distinguir entre mayúsculas y minúsculas . Los documentos de PostgreSQL dicen: „Si declara una columna como ÚNICA o CLAVE PRIMARIA, el índice generado implícitamente es sensible a 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]".
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.
Personalmente, no utilizo ninguna información para la clave principal al diseñar la base de datos, ya que es muy probable que necesite modificar cualquier información más adelante. La única razón por la que proporciono la clave principal es que es conveniente realizar la mayoría de las operaciones de SQL desde el lado del cliente, y mi elección ha sido siempre de tipo entero de incremento automático.
Sé que se trata de una entrada tardía, pero me gustaría agregar que las personas que abandonan las cuentas de correo electrónico y los proveedores de servicios recuperan la dirección y permiten que otra persona la use.
Como @HLGEM señaló: "[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 deseara 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, de acuerdo con las leyes locales, podría encontrarse con agua caliente.
Por lo tanto, nunca usaría datos como direcciones de correo electrónico, placas de matrícula, etc. como claves principales, ya que no importa qué tan singulares parezcan estar fuera de su control y pueden proporcionar algunos desafíos interesantes que quizás no tenga tiempo de tratar.
Sí, es mejor si usas un entero. 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
);
Sí, es una clave primaria incorrecta porque los usuarios querrán actualizar sus direcciones de correo electrónico.
Si es simplemente una cuestión de exigir que el correo electrónico sea único, puede crear un índice único con esa columna.
Si no tiene un valor int como clave principal, las inserciones y recuperaciones serán muy lentas en los datos de gran tamaño.
Su colega tiene razón: use un entero de autoincremento para su clave principal.
Puede implementar la singularidad del correo electrónico ya sea en el nivel de la aplicación o puede marcar la columna de su dirección de correo electrónico como única y agregar un índice a esa columna.
Agregar el campo como único le costará la comparación de cadenas solo cuando se inserta en esa tabla, y no al realizar uniones y verificaciones de restricciones de clave externa.
Por supuesto, debe tener en cuenta que agregar restricciones a su aplicación en el nivel de la base de datos puede hacer que su aplicación sea inflexible. Siempre preste la debida atención antes de hacer que cualquier campo sea "único" o "no nulo" simplemente porque su aplicación necesita que sea única o no esté vacía.
También señalaré que el correo electrónico es una mala elección para crear 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 une a otras tablas con esa clave, tendrá que actualizar las otras tablas también, lo que puede ser un gran éxito de rendimiento cuando una empresa cliente completa cambie sus correos electrónicos (lo que he visto que sucede).
Use un GUID como clave principal ... de esa manera puede generarlo desde su programa cuando haga un INSERT y no necesita obtener una respuesta del servidor para averiguar cuál es la clave principal. También será único en todas las tablas y bases de datos y no tiene que preocuparse por lo que suceda si trunca la tabla algún día y el incremento automático se restablece en 1.
debe usar una clave primaria entera. Si necesita que la columna de correo electrónico sea única, ¿por qué simplemente no establece un índice único en esa columna?
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
puede aumentar el rendimiento mediante el uso de la clave principal entera.