Duda con restriciones on update on delete

[saumal20]

Ola...espero ke me puedan ayudar con esto de las restriciones, es ke ando un poco perdido. Bien para entender eso hize un ejm:

Tengo 1 tabla:

Código MySQL:

create table ejm1(
var1 int,
var2 int,
cantidad int,
primary key(var1),
index var(var1)
)engine = innodb;
 

y tengo otra:

Código MySQL:

create table ejm2(
co1 int primary key,
co2 int,
var1 int,
total int,
foreign key(var1) references ejm1(var1) on UPDATE cascade,
index var(co1, var1)
)engine = innodb;
 

insertamos datos :

Código MySQL:

insert into ejm1 VALUES (1,2,3);
 

luego tengo un procedimiento almacenado:

Código MySQL:

DELIMITER $$
create procedure ejm()
    BEGIN
        DECLARE aa int(10);
        select e1.cantidad -- into @aa
        from ejm1 e1, ejm2 e2
        where e1.var1 = e2.var1 and e1.var1 = 1;
        insert into ejm2 values (1,2,1,@aa);
    END$$
 

DELIMITER ;

este coge el valor de la cantidad de ejm1 y lo mete en total en ejm2

ahora llamamos al PA:

Código MySQL:

call ejm();
 

hacemos un select a ejm y sale: 1,2,3

despues hacemos un select a ejm2 y sale: 1,2,1,3

bien...despues viene mi duda, hacemos un update a ejm1:

Código MySQL:

update ejm1
set cantidad = 10
where var1 = 1
 

hacemos un select a ejm y sale: 1,2,10 ... hasta ahi bacan

pero despues hacer un select a ejm2 sale -> 1,2,1,3

no se deberia actualizar, o estoy entendiendo mal lo del uddate y delete...necesito entonces un trigger ke me actualize la tabla ejm2, cuando actualize datos en la tabla ejm1??? o estoy haciendo mal lo del update o cascade????? help me

[gnzsoloyo]

El ON UPDATE CASCADE tiene por objeto que si la clave primaria de la tabla origen es modificada, se modifiquen en cascada todas aquellas FK que se correspondían con la clave anterior. No afecta a ningún otro campo.
¿Eso es lo que estás buscando hacer?

Por otro lado, el SP que has hecho tiene un error: la variable declarada aa no es la misma variable que @aa. Esta última es una variable de usuario que existe en la sesión, mientras que la primera es una variable local del SP y sólo existe dentro de él.
Las variables de sesión no necesitan ser declaradas pero deben ser incializadas antes de ser usadas porque carecen de tipo y su valor al invocarla es NULL.
Ten cuidado con confundir MySQL con SQL Server. LSP tienen diferente uso de variables y diferentes sintaxis.

[saumal20]

Iniciado por gnzsoloyo

El ON UPDATE CASCADE tiene por objeto que si la clave primaria de la tabla origen es modificada, se modifiquen en cascada todas aquellas FK que se correspondían con la clave anterior. No afecta a ningún otro campo.
¿Eso es lo que estás buscando hacer?

Por otro lado, el SP que has hecho tiene un error: la variable declarada aa no es la misma variable que @aa. Esta última es una variable de usuario que existe en la sesión, mientras que la primera es una variable local del SP y sólo existe dentro de él.
Las variables de sesión no necesitan ser declaradas pero deben ser incializadas antes de ser usadas porque carecen de tipo y su valor al invocarla es NULL.
Ten cuidado con confundir MySQL con SQL Server. LSP tienen diferente uso de variables y diferentes sintaxis.

si eso es lo ke keria, entonces tendria ke hacer un trigger , graxias man, por las dos cosas

[gnzsoloyo]

¿Un TRIGGER para hacer qué?

¿Podrías explicar un poco el caso real y no el simulado? porque me parece que estuvieses intentando hacer tareas innecesarias.

¿En qué consiste la historia?

[saumal20]

Iniciado por gnzsoloyo

¿Un TRIGGER para hacer qué?

¿Podrías explicar un poco el caso real y no el simulado? porque me parece que estuvieses intentando hacer tareas innecesarias.

¿En qué consiste la historia?

por ejm...tengo un pedido con un detalle de pedido, y en el caso que cambie algo en detalle de pedido, por ejm el precio del producto, tengo ke notar ese cambio en el total del pedido, lo ke esta en la tabla pedido

[gnzsoloyo]

Normalmente los totales (datos calculables en la jerga de Base de datos) no se almacenan en la tabla porque los mismos, precisamente, se pueden calcular mientras se realiza la consulta de datos. Se considera que lo único que hacen es ocupar espacio sin generar ninguna ventaja.
Al menos eso es lo que te enseñan en la facultad sobre esos temas.
Sólo se almacenan totales cuando son afectados por operaciones que no se documentan, y que son mu pocas. Pueden guardarse los importes de descuento, totales cobrados o pagados, pero nunca la suma de una cuenta, ya que eso requiere tareas extra como la que te ocupa, y que no necesitarías si hubieses almacenado sólo precio y cantidad....

Tenlo en cuenta. Te ayudará a modelar bases más eficientes.

[saumal20]

Iniciado por gnzsoloyo

Normalmente los totales (datos calculables en la jerga de Base de datos) no se almacenan en la tabla porque los mismos, precisamente, se pueden calcular mientras se realiza la consulta de datos. Se considera que lo único que hacen es ocupar espacio sin generar ninguna ventaja.
Al menos eso es lo que te enseñan en la facultad sobre esos temas.
Sólo se almacenan totales cuando son afectados por operaciones que no se documentan, y que son mu pocas. Pueden guardarse los importes de descuento, totales cobrados o pagados, pero nunca la suma de una cuenta, ya que eso requiere tareas extra como la que te ocupa, y que no necesitarías si hubieses almacenado sólo precio y cantidad....

Tenlo en cuenta. Te ayudará a modelar bases más eficientes.

pero ke pasa si cambia el precio del producto, esa cantidad no tendria ke estar reflejada en tabla pedido, xq afecta el total, ya ke se cambio el precio en detalle pedido. o no?????

[gnzsoloyo]

Para eso se usa otras relaciones que están vinculada con la tabla de Stock, en la que se encuentran los productos y sus existencias en almacén.
Lo que se hace es crear una o más tablas vinculadas a los productos y que almacenen las variaciones de precios de compraventa de los mismos en forma histórica. De ese modo se pude saber, conociendo la fecha de presupuestación o emisión del pedido, cuál es el precio que correspondía pagar en ese momento.
Además, ese tipo de relaciones permite hacer balances donde se pueda compensar las variaciones del IPC (indice de precios al consumidor) de modo que los resultados sean fiables.

El problema del modelo tal como lo planeas es que para que se pueda hacer un análisis de resultados de ventas deberás contar con documentación extra, además de lo que está en la base de datos, o de lo contrario los números no cerrarán. En lugar de eso estas relaciones aportan los datos necesarios sin tener que agregar nada ni consultar nada que no esté en la base.

Es posible que esto te parezca demasiado complejo, y tal vez sea cierto, pero ten en cuenta que las bases de datos se diseñan no para el funcionamiento actual sino para dar soporte al funcionamiento en el futuro. Porque llegado el caso, el cliente no estará muy contento si por un cambio de planes de venta tienes que plantearle una migración a otro modelo de bases de datos... Con todo lo que eso implicaría.