Vamos por partes (decía Jack el Destripador):
Primero que nada, no te compliques tratando de deducir cosas que ya están resueltas de antemano. Simplemente hay que saber cómo funcionan, y cuándo aplicarlas...
Sabemos que:
- De acuerdo al modelo relacional, toda relación (tala del modelo físico) tiene que poseer una clave primaria, la que debe ser única, no nula e identificar unívocamente a una única tupla de la relación.
- De acuerdo a las técnicas de normalización, pueden hallarse en una relación dada, una o más de una clave candidata. Pero solo una es efectiva y eficiente. Cuál es la efectiva y eficiente, eso es un tema de análisis de otro nivel. A las formas normales no les importa en tanto se cumplan sus requerimientos.
- Como regla general, para poner una relación en 3FN, todos los atributos de la relación deben depender completamente de la clave, y sólo si no existe una CC posible, entonces se debe agregar una clave artificial, preferentemente numérica.
Infortunadamente, cuando llega el momento de crear las tablas, es mucho más fácil para el diseñador poner una clave autoincremental, que tratar de ceñirse a las FN.
, y por eso terminan inventando PK numéricas en todas las tablas, incluyendo las que no lo necesitan.
En tu caso, el
cliente_nroidentifcacion podría ser una clave efectiva y eficiente... salvo por un problema:
Estás proponiendo que pueda haber más de un tipo de documento de donde tomar ese dato, y eso puede producir problemas, ya que no puedes establecer si documentos de diferentes orígenes no puedan compartir números,
aún siendo diferentes personas.
Si nos atenemos al modelo de FN, requeriría de
otro atributo para darle seguridad, o reducir los tipos de documento a
uno sólo (que en bases de datos de uso global no es posible). Cualquier otra opción generará inconsistencias eventualmente.
La dirección de correo electrónico es mucho más eficiente en este caso que el número de documento para este fin, pero adolece de un problema:
Ocupará mucho espacio almacenarlas (8 bytes máximo de un BIGINT contra más de 250 de un VARCHAR). Esto puede traer ciertos problemas a la hora de contar el almacenaje y también en las actualizaciones, debido a los índices. De todos modos puede ser que convenga.
Aún así, este caso requiere que antes de guardar un registro nuevo se
verifique contra la base
que no exista ya otro registro con el mismo e-mail. No te olvides que el hecho de que alguien lo use no significa que le pertenezca... Y con eso puede darse que se dupliquen.
Revisa bien cuál atributo o grupo de atributos te servirá de PK si no quieres usar un autoincremental.
Cita: Pero que pasa si un cliente me dice que ahora tiene nuevo correo, entonces selecciono sus datos antiguos y cambio el correo, pero no va a actualizar porque el update where se basa en el dato antiguo para actualizar, o sea si antes en el registro estaba guardado como
[email protected], y me dice que cambie a
[email protected] no va a encontrar ese dato en la tabla y por lo tanto no va a haber actualizacion.
Esto es un problema estrictamente de SQL.
Cuando se hace un UPDATE de una PK es conveniente saber dos cosas:
1) Si la PK se usa como FK en otras tablas, en esas debe estar definida como ON UPDATE CASCADE, para no tener que realizar cambios manualmente.
2) Un UPDATE no opera, como pareces decir, actualizando primero y comparando después. No. Actualiza luego de encontrar, lo que significa que sólo cuando haya ubicado el registro físico realiza el cambio. No antes. Y en ese momento no está apuntando a la clave, sino al registro...
No te preocupes de cómo hace. Simplemente lo hace.
