Comunidad Gambas-es

a ver shordi la propuesta es esta.

estoy trancado con lo de entender la llave foranea, por tanto necesito un ejemplo bien simple de aplicación para poder introducirme en el profesionalismo en base de datos.

voy hacer un ejemplo y vos me iras guiando hacia la solución.

la idea es hacer lo que no hice y debí hacer en el programa taller

el ejemplo es una tabla deudas y otra entregas y vincularlas usando foreign key.

cuando tenga algo hecho lo subo acá y vos me vas guiando hasta lograr el objetivo que es ver el funcionamiento de foreign key.

primero voy a planificar el uml
después hacer la interfaz
luego lo subo acá y vos haces las primeras correcciones.


te parece?

arranco con el diseño vos mira y hace las correcciones correspondientes.

Ok. La imagen es correcta. Pero es mucho más fácil de lo que crees. El asunto es que una vez establecida la integridad referencial en la BD, el mantenimiento de la misma se deja en sus manos, por lo que tú no tienes que preocuparte de nada. Es decir, supon que tienes esta estructura:
Cliente
facturas del cliente
items de factura
pagos de factura

Es decir por cada registro de cliente puede tener varias facturas y por cada factura puedes tener varios ítems y varios pagos

Una vez bien establecida la integridad referencial, para eliminar toda la estructura para un cliente basta con "delete from cliente where id_cliente=numero"

y la base de datos solita te hace la limpia de la tabla facturas, items y pagos.

Es decir el código de gambas con integridad referencial en la base de datos es mucho más simple que el código que escribes sin ella.
Tampoco tienes que preocuparte por verificar que el id_cliente de pagos esté bien o mal o que se puedan grabar facturas sin clientes, etc. etc.

Más simple, más efectivo.

Saludos

en el campo entrega hay que poner la suma de las entregas de la deuda

el saldo se calcula en el evento change de valuebox entrega supongo

y como decís vos cuando una deuda se borra hay que borrar su entregas vinculadas.(eso lo resolvería la misma tabla)

aquí el DDL shordi (opa el tipo esta estudiando eeee jajajaj habla de DDL)



fijate si esta bien

creo que algunos NOT NULL están de mas

fecha de ingreso porque de repente no se exacta la fecha y dejo para ponerla en otro momento
el monto porque tal vez debo un producto pero no se el precio
también entrega porque aun no he hecho entregas
sigo razonando.

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.

shordi voy a ver tus correcciones y te presentare nuevamente las sentencias para nuevas correcciones.


una cosa olvídate de facturas o cualquier otra cosa solo enfocate en dos tablas, deuda y entregas no existe nada mas, esta base esta orientada a aprender y dar un ejemplo de como se hace.

Citar:

una cosa olvídate de facturas o cualquier otra cosa solo enfocate en dos tablas, deuda y entregas no existe nada mas

Confimado: Eres un prestamista de los de interés compuesto...

naaaa que prestamista ni prestamista

aqui dejo mis avances:


Activar pragma foreign_keys para que (on delete cascade) haga su trabajo de borrado en cascada.
pragma foreign_keys=1

Desactivar foreign_keys(lo que hara que borre la deuda pero no borrara las entregas dejando basura en la tabla de datos y anulando el on delete cascade:
pragma foreign_keys=0

Ver estado de foreign_keys:
pragma foreign_keys


he estado probando en la consulta sql de gambas y me dio una sensación agradable al ver que al borrar las deudas iba a la tabla entregas y también se notaba que había borrado las entregas.

jajajaj al principio probe y no borraba las entregas y me acorde de que hay que activar el pragma foreign_key

me agrada este ejemplo que estamos tratando de hacer ya estoy aprendiendo mucho.

a ver sensei como lo ves?