|
Hola Elite237,
Como te han dicho, no es una práctica muy recomendable. Se supone que una clave es única. Además conlleva muchos peligros.
Si se elimina un registro, y hay otros registros relacionados a éste (es decir, existe una relación Maestro-Detalle) estos últimos registros apuntarán a un valor inexistente, por tanto se rompe el esquema de intregridad referencial.
Hay en forma breve dos alternativas:
1. O bien eliminas también los registros relacionados. Esto es conocido como efecto CASCADA.
2. O bien, en vez de eliminarlos, modificar la clave foránea de estos registros para que estén relacionados a otro registro maestro.
El segundo caso es sólo aplicable bajo ciertas circunstancias y depende fuertemente de las necesidades, requisitos.
¿Porqué deseas llevar a cabo ese extraño requisito? ¡Rompe los esquemas!
Ahora bien, si dicho campo no es en realidad una clave primaria o foránea, sino un campo cualquiera (una pseudo-clave) se puede implementar un triggers o algún procedimiento almacenado que se encargue de llevar a cabo toda la operación.
Existe, es algo habitual, una tercera opción que suele darse frente a los casos de borrados. En vez de hacer un borrado físico, se lo lleva a cabo a nivel lógico. ¿Cómo? Fácil, se añade un campo "booleano" llamado hipotéticamente Borrado. Por ejemplo si tiene el valor 0, significa que el campo no ha sido borrado, en otro caso, significa que se ha borrado. Dije "booleano" porque no todos los motores tienen un campo de tipo boolean (True, False).
Te comento todo esto porque son opciones, alternativas y cada una tiene sus pros y contras. Dependiendo de las circunstancias se puede llevar a cabo algunas o todas de las que te he comentado.
Mientras más sepamos sobre tu caso, mejor te podremos asesorar.
Espero que comprendas que lo que quieres hacer viola una de las reglas fundamentales de bases de datos.
Saludos,
|