Hay cosas que no entiendo:
CREATE TABLE deudas (
"id_deuda" integer PRIMARY KEY autoincrement NOT NULL,
"f_ingreso" datatime NOT NULL, --->¿Esto qué es? ¿La fecha en que se generó la deuda? para eso tienes la fecha en la factura (salvo que seas un prestamista, claro
:mryellow:) Además ¿Por qué datatime?¿Es importante la hora? mejor date a secas... digo.)
"monto" float (6,2) NOT NULL,
"entregas" float (6,2) NOT NULL, ---->¿Esto que és? los ingresos ya los tienes la tabla entregas...
"saldo" float (6,2) NOT NULL, ---->¿Esto qué es? El saldo te lo da la tabla entregas...
"motivo" text NOT NULL
)
CREATE TABLE "entregas" (
"id_entrega" integer PRIMARY KEY autoincrement NOT NULL,
"id_deuda" integer NOT NULL,
"f_entrega" datatime NOT NULL, --->Lo mismo que la otra fecha, mejor date...
"cantidad" float (6,2) NOT NULL,
--->aquí sí podrías colocar el saldo, no es estrictamente necesario, pero sí cómodo a la hora de hacer consultas.
FOREIGN KEY (id_deuda) REFERENCES deudas(id_deuda) ON DELETE restrict --->¿seguro? Yo creo que se impone más bien un cascade. Deja a
gambas que decida si se puede o no eliminar una deuda, pero si restringes en la DB no podrás eliminar una deuda mientras existan entregas, lo cual es incómodo a la hora de eliminar la deuda.
La filosofía de fondo es nunca dupliques información. Malgastas espacio y favoreces la aparición de errores... además de complicarte la vida en el código.
Por ejemplo: Si colocas el saldo en la tabla deudas, además de perder los saldos parciales, tienes que comprobar que es correcto siempre que modifiques, grabes, elimines o añadas una entrada. Eso es, cuando menos incómodo y en caso de error en alguna de esas transacciones fuente de errores.
Coloca el saldo en cada entrega y haz una vista donde aparezca la cantidad debida, el total entregado y el saldo actual con unos sencillos cálculos sobre las tablas. Eso no falla nunca y no tienes que preocuparte de actualizaciones ni demás.