Clave primaria en campo email

[mdromed]

Hola a todos.
Vereis tengo una tabla de usuarios en la cual cada usuario tiene un campo email.
El caso es que quiero que nunca se repita el email de un usuario.
He pensado en poner dicho campo email como "PK" (clave primaria) para que asi la integridad de la BD se mantenga aun si hay algun fallo en la programcion php.

Hasta ahora la PK era un campo autonumerico que era el "idusuario".

¿Que creeis que es mas correcto, poner como PK el email o el idusuario?

A la hora de los indices, ¿la BD irá mas lenta si pongo como PK el email en vez del idusuario?

Gracias a todos de antemano!
Saludos

[ah_puch]

Iniciado por mdromed

Hola a todos.

Hasta ahora la PK era un campo autonumerico que era el "idusuario".
¿Que creeis que es mas correcto, poner como PK el email o el idusuario?

A la hora de los indices, ¿la BD irá mas lenta si pongo como PK el email en vez del idusuario?

Saludos

y por que no generas una llave compuesta a partir del correo y el id de usuario.

[DooBie]

Siempre que en un primary key uses un campo alfanumerico, la tabla ira mas lenta, por que no pones el primary key al idusuario y asignas el campo email como unique?

[mdromed]

Iniciado por ah_puch

y por que no generas una llave compuesta a partir del correo y el id de usuario.

Tambien lo he pensado pero es que si lo hago asi, al insertar un email repetido en la BD se lo tragará y creará algo asi como esto:

Código HTML:

ID                   EMAIL
_________    _______________________
1                    [email protected]
2                    [email protected]
 

Y eso es justo lo que quiero evitar.

De todas formas segun la definicion que da la Wikipedia el email seria una PK valida:

se llama clave primaria a un campo o a una combinación de campos que identifica de forma única a cada fila de una tabla.

[mdromed]

Iniciado por DooBie

Siempre que en un primary key uses un campo alfanumerico, la tabla ira mas lenta, por que no pones el primary key al idusuario y asignas el campo email como unique?

Ok, he seguido tu consejo y he hecho eso:

La PK es el idusuario y el campo email tiene un indice UNIQUE.
Es a eso a lo que te referias no?

El indice unique lo he creado asi:

Código MySQL:

alter table usuarios add unique(email);
 

Pero lo he probado y sí que me deja meter repetido el mismo email en varios registros diferentes.

¿Que estoy haciendo mal?

[quimfv]

He repasado el manual por las dudas pero un indice unico si esta bien creado evita las repeticiones

Del manual

A UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. For all engines, a UNIQUE index allows multiple NULL values for columns that can contain NULL.

La sintaxis correcta de creación de un indice es, otra vez del manual:

Código MySQL:

ALTER TABLE tbl_name
ADD INDEX [index_name] [index_type] (index_col_name,...)
 

en tu caso seria

Código MySQL:

ALTER TABLE usuarios ADD INDEX index_email UNIQUE (email);
 

ADD INDEX no es opcional, el nombre del indice y el tipo si lo son ...

creo

Quim

[mdromed]

Ok ahora si ha funcionado.
Pero entonces como conclusion podemos decir que esa es la mejor manera:

el idusuario PK y el email como indice UNIQUE.

O es mejor poner como PK al email????

[DooBie]

No te se decir si es la mejor o no, pero es una opcion, que tiene ventajas a la hora de hacerlo solo como pk, con lo cual, yo lo haria asi ya que sabemos que funciona.

[gnzsoloyo]

Eso es más una decisión de diseño.
Dependería, por ejemplo, de si puede darse usuarios que no posean e-Mail (cosa improbable hoy en el mundo), o si puede darse que varios compartan el mismo, lo que crearía problemas para la persona...
Puede no ser lo suficientemente práctico por cuestiones menores: Errores de tipeo, por ejemplo, pero sigue siendo una decisión del diseñador del sistema.

[quimfv]

En teoria un identificador debe ser solo eso un identificador, es mejor que en si mismo no signifique nada.

Imagina que un usuario por lo que sea decide cambiar de email se te va a presentar un problema si tienes tablas vinculadas... cambiar una PK siempre es un problema...

Pero como te dice gnzsoloyo siempre que da la libertad del diseñador de tomar sus decisiones.

Quim

[mdromed]

Iniciado por quimfv

En teoria un identificador debe ser solo eso un identificador, es mejor que en si mismo no signifique nada.

Imagina que un usuario por lo que sea decide cambiar de email se te va a presentar un problema si tienes tablas vinculadas... cambiar una PK siempre es un problema...

Pero como te dice gnzsoloyo siempre que da la libertad del diseñador de tomar sus decisiones.

Quim

Si, el usuario puede cambiar el email, claro.
Entonces es mejor PK el identificador y el email como campo UNIQUE.

Gracias

[mdromed]

Iniciado por gnzsoloyo

Eso es más una decisión de diseño.
Dependería, por ejemplo, de si puede darse usuarios que no posean e-Mail (cosa improbable hoy en el mundo), o si puede darse que varios compartan el mismo, lo que crearía problemas para la persona...
Puede no ser lo suficientemente práctico por cuestiones menores: Errores de tipeo, por ejemplo, pero sigue siendo una decisión del diseñador del sistema.

Todo usuario es obligatorio que tenga un email, sí.
Y no pueden usar el mismo email varios usuarios.
Para ti entonces ¿Es mejor que el id sea la PK y el email un campo Unique no?

[gnzsoloyo]

Si. En eso estoy de acuerdo con quimfv, el problema lo tendrías fundamentalmente ante la posibilidad de que un usuario cambie el e-Mail (yo mismo he cambiado el principal tres veces en dos años por cosas del trabajo), lo que te dará problemas para el caso.
Es mejor que sean atributos separados.