Re: Ejemplo Practico De FOREIGN KEY (por V3ctor Y Shordi)
Ahora sí. Como ejemplo vale. Pero si se ha de hacer didáctico de verdad, sigo diciendo que falta una tabla... o dos. A saber:
Una tabla de deudores donde se pueda establecer un ejemplo de on delete restrict on update cascade De manera que la BD nos restrinja el eliminado de un deudor si hay deudas abiertas (eso sería "perdonar" la deuda y perder dinero) y una tabla de motivos de de deuda, relacionada con deudas donde se especifiquen los motivos válidos, los plazos para cada motivo y el interés a cobrar según tipo (o plazo)
Con esta tabla se podría aplicar un Trigger (un procedimiento almacenado que se ejecuta dentro de la BD cuando ocurra un Evento concreto) en la propia DB que, por un lado on update cascade, y por otro ejecutase una actualización de tipos y recalculado de saldos en la tabla de pagos realizados. Es decir, si a ésta deuda le aplico un interés del 3% y luego cambio el interés en la tabla de motivos, se actualice tanto en la tabla de deudas como en la de pagos, recalculando los saldos en cada pago parcial (este sería una de las razones por las que desaconsejaba más arriba grabar los saldos: es mejor calcularlos).
Este procedimiento se puede hacer en nuestro programa de
gambas, pero un Trigger hace que nos olvidemos del tema para siempre.
Por otra parte, respecto a los NOT NULL, hay que pensárselos muy bien. Por ejemplo se lo has quitado a la fecha y al monto. Eso es un absurdo informático: No puedes dar de alta una deuda si no sabes cuándo se produjo ni en qué cantidad. Deben ser NOT NULL (y dejar la decisión de si hay que darla de alta o no a la tabla de facturas (sí, ya lo sé, no existe aquí) donde se especifica si la factura está pagada o no y si el pago es en cuotas o de una. Para el ejemplo de Integridad Referencial, puede valer así, pero en la vida real, cuando se habla de dinero, hay que ser muy, muy cuidadoso con esas cosas.
Saludos.
Albacete
Foro 
Uruguay
