example - CHAR() o VARCHAR() como clave principal en una tabla ISAM mySQL?

varchar max

Question

Necesito una tabla simple con un nombre de usuario y un campo de contraseña en mySQL. Como los nombres de usuario deben ser únicos, tiene sentido para mí convertirlos en la clave principal.

¿Es mejor usar CHAR () o VARCHAR () como clave principal?

Answer 1

Me esforzaría mucho para NO usar CHAR () o VARCHAR () como PK, sino que usaría un int con un auto_increment. Esto le permite usar ese user_id en tablas secundarias si es necesario y las consultas en PK deben ser más rápidas. Si tiene que usar un CHAR () o un VARCHAR (), iría con el CHAR () ya que es un ancho fijo.

No estoy 100% seguro de cómo MySQL trata con VARCHAR (), pero la mayoría de los motores de base de datos tienen que hacer un poco de magia para ayudar al motor a saber dónde terminan los campos VARCHAR () y dónde comienza el siguiente campo, un CHAR ( ) lo hace directo y evita que el motor tenga que pensar demasiado.

Answer 2

No veo que CHAR use mucho en ninguna base de datos MySQL en la que haya trabajado. Yo iría con el VARCHAR

Para un CHAR (30), por ejemplo, los 30 caracteres enteros se almacenan en la tabla, lo que significa que cada entrada ocupará el mismo espacio, incluso si su nombre de usuario tiene solo 10 caracteres.

Usando VARCHAR (30) solo usará suficiente espacio para almacenar la cadena que ha ingresado.

En una mesa pequeña no hará mucha diferencia, pero en una mesa más grande, el VARCHAR debería demostrar que es más pequeño en general.

Answer 3

[Me esforzaría mucho para NO usar CHAR () ni VARCHAR () como PK, sino que usaría un int con un auto_increment en su lugar.] +1

Ponga una restricción única del nombre de usuario pero use el campo int como PK

Answer 4

también puede usar un índice de identificación de usuario, es mucho más rápido para combinaciones vs char / varchar. los dos segundos que lleva agregar que ahora podría ahorrarle mucho tiempo más tarde si accidentalmente tiene que expandir la funcionalidad de su esquema.

algunos escollos para pensar:

• digamos que agregamos algunas tablas en una fecha futura, ¿qué pasa si alguien quiere cambiar un nombre de usuario?
• dicen que la aplicación es más exitosa de lo que creemos, y tenemos que mirar la optimización, ¿realmente desea volver a hacer el esquema en este punto para reducir la sobrecarga de un índice varchar''ed?