En la nueva versión de el Puchero he decidido tratar con rigor el tema de las claves ajenas y aplicar la regla de integridad referencial para claves ajenas. Estas son las reglas que voy a seguir:
- Regla de los nulos: permitir valores nulos – en mi casi en blanco – en los campos que son clave ajena.
- Regla de borrado: al borrar la clave primaria los registros que contengan ese valor de clave ajena se pondrán a nulo.
- Regla de modificación: al modificar un valor de clave primaria la modificación se propaga a la clave ajena.
Una cosa que me parece especialmente mal resuelta es la aplicación de la restricción de modificación de la clave principal. El usuario puede haber cometido un error de tipografia, por ejemplo, y tener que modificar uno a uno los registros que contienen la clave ajena antes de permitir el borrado de la clave principal. Menudo latazo.
Igual ya lo has planteado (no he leido el artículo que enlazas) pero yo suelo utilizar claves artificiales para los enlaces entre tablas, de esa forma no dependo de lo que introduce el usuario, es más, creo que es mala decisión utilizar el típico DNI o número de documento para enlazar datos ya que considero que cualquier dato que introduce el usuario es susceptible de ser modificado.
En mi caso en Clipper me hice un generador de claves únicas basándose en una serie de contadores, el reloj, una parte aleatoria, etc.
Con Delphi hice una versión mejorada del mismo utilizando el generador de GUIDs de Windows, pero «comprimiendo» el GUID para que ocupe menos.
Da una potencia tremenda, puedes enlazar datos incluso con registros vacíos, sin que el usuario introduzca nada.
De todas formas, estos temas sin un SGDB que los implemente, hacerlo a nivel aplicación es un esfuerzo bastante grande.
Suerte.
Jose Luis,
La integridad referencial es algo que gustó muchísimo cuendo estudie Bases de Datos Relacionales, sobre todo cuando el sistema lo hace de forma automática (MS SQL Server / Oracle) dependiendo de lo que se le programe en el momento de diseño de la Base de Datos.
Para Clipper hice algo parecido, pero con intervención del usuario, y usando siempre códigos generados por el programa o claves artificiales. Aquellos programas que hice en Clipper con el sistema de intervención del usuario funcionaban bien cuando solo había un responsable del mantenimiento de los datos, en cuanto aparecían varios se corria el riesgo de perder información. La generación de claves artificiales no era más que un contador autoincrementado por el programa cada vez que se añadía un registro.
Saludos,
Jose Luis:
Antes de definir las reglas de integridad referencial, debes definir las reglas de las claves primarias.
1) La clave primaria debe ser única.
2) La clave primaria no debería cambiar.
Es muy discutido este último punto, no existe una regla específica, pero si se tiene como norma, no tendras problemas con una regla de integridad referencial de modificaciones.
Sobre la Regla de borrado, no creo que sea la mejor opción.
Muchas veces ocurre que un campo, es clave ajena, pero a su vez es clave primaria o parte de una clave primaria en otra tabla, con lo cual, esa regla estaría rompiendo una regla aún mayor, la de no tener valores nulos ni repetidos en una clave primaria.
Creo que la regla de borrado, podría aplicarse únicamente con restricciones.
Un registro de una tabla no debe borrarse, si su clave primaria es clave ajena en otra tabla, y el campo pertinente pertenece a la clave primaria de esa otra tabla.