Ayuda con trigger en mysql

[jiote]

bueno desde hace unos dias estoy asiendo un proyecto en java para una base de datos..... pero me detengo en una cuestion... pongo una image del modelo que realize para que entiendan mejor

lo que intento aser es un disparador o un metodo que me permita condicionar la insercion de valores nuevos en la tabla "tablas" de tal modo que no se pueda insertar mas datos si la suma de los registros con la misma id de productor es mas grande que el campo prouctor.id no se si me explico bien pero agradeceria ayuda

[bavarol]

Yo lo haria con un trigger "instead of insert", dentro de el controla lo que insertas, ya sea con ayuda de la tabla "inserted" (sabes cual es, no? Bueno, no se si con ese nombre en MySQL, en SQL Server si existe, creo que existe algo asi en MySQL pero no se si con el mismo nombre) como sin ella lo unico que te queda es exponer las condiciones que dices, ya sabes, row_count() despues de una insercion en la tabla que dices y compararlo con la id que comentas.

[gnzsoloyo]

Me temo, bavarol, que no existe ese tipo de TRIGGERS en MySQL.
Un TRIGGER no puede indicar operaciones DML contra la misma tabla que lo dispara, ni tampoco contra tablas que posean TRIGGERs contra la tabla que lo inició (procesos anidados).
Infortunadamente, deberá gestionar esto en la aplicación.

[jiote]

Iniciado por gnzsoloyo

Me temo, bavarol, que no existe ese tipo de TRIGGERS en MySQL.
Un TRIGGER no puede indicar operaciones DML contra la misma tabla que lo dispara, ni tampoco contra tablas que posean TRIGGERs contra la tabla que lo inició (procesos anidados).
Infortunadamente, deberá gestionar esto en la aplicación.

me puse a leer mas del tema y desafortunadamente como dices me encuentro con eso... seguire buscando a ver si encuentro algo que me ayude, si no tendre que gestionarlo con la aplicacion aunque me hubiera gustado hacer que mysql lo hiciera para que mi programa se conecte con cualquier base de datos.

[gnzsoloyo]

aunque me hubiera gustado hacer que mysql lo hiciera para que mi programa se conecte con cualquier base de datos.

Eso es casi una fantasía...
El principal escollo contra el que cocarás está precisamente en los lenguajes de procedimientos. Como no existe un estandar ANSI, cada DBMS implementa un set de instrucciones diferente y hasta extensiones de funciones para datos que son incompatibles entre sí (dale una mirada solamente a las que manejan fechas y lo verás).
Finalmente las soluciones terminan pasando por crear clases específicas para determinados DBMS o usar Frameworks ya desarrollados para el problema, que ya han considerado estas cosas.
Todos chocamos tarde o temprano con este problema de falta de estádares...

[bavarol]

Iniciado por gnzsoloyo

Me temo, bavarol, que no existe ese tipo de TRIGGERS en MySQL.
Un TRIGGER no puede indicar operaciones DML contra la misma tabla que lo dispara, ni tampoco contra tablas que posean TRIGGERs contra la tabla que lo inició (procesos anidados).
Infortunadamente, deberá gestionar esto en la aplicación.

Vaya, una pena, de todas maneras es mas una cuestion sintactica que semantica, en SQL Server no hay Before insert, por en contrario hay instead of insert, creo que nuestro amigo puede ayudarse entonces con el before insert.

Sobre lo de ir contra la misma tabla, no se a que te refieres yo me referia con lo de instead of insert a ayudarse de la tabla temporal de sistema "inserted" que existe en SQL Server, siempre se puede hacer lo que quiera con ella y segun las condiciones que expone el companiero, pasarla a la tabla donde queremos realmente insertarla ( o en un momento dado NO).

Un saludo

[jiote]

bueno finalmente decidi gestionarlo con la aplicacion...cuando la termine se las mostrare para que me den su punto de vista ya que soy un novato en esto de la programacion gracias a los dos por su ayuda

[gnzsoloyo]

Sobre lo de ir contra la misma tabla, no se a que te refieres yo me referia con lo de instead of insert a ayudarse de la tabla temporal de sistema "inserted" que existe en SQL Server, siempre se puede hacer lo que quiera con ella y segun las condiciones que expone el companiero, pasarla a la tabla donde queremos realmente insertarla ( o en un momento dado NO).

Me refiero que si tienes un TRIGGER definido, por ejemplo, para un INSERT en la tabla A, el código de ese trigger no puede realizar INSERT, DELETE, UPDATE, ALTER o DROP sobre la misma tabla A, porque en ese momento está bloqueada.
Tampoco puede hacer una operación de clase DML (INSERT, DELETE; UPDATE) sobre una tabla B si la tabla B tiene a su vez un TRIGGER que realice una operación DML sobre la tabla A (nested process).
Lo que si puedes hacer es crear otras tablas (temporales o no) o realizar operaciones sobre los valores del nuevo registro (INSERT) o del viejo (UPDATE).
Finalmente: No se pueden crear variables de tipo TABLE porque en MySQL no existe ese tipo de dato. Existen las tablas TEMPORARY y MEMORY, que cumplen funciones parecidas.
Tampoco se puede cancelar un INSERT/ UPDATE/ DELETE en proceso desde su TRIGGER.

Como dije: Hay cosas que son incompatibles entre diferentes BDMS. Por eso las migraciones son tan complejas.

[jiote]

Bueno investigue un poco mas y formule la siguiente respuesta espero que me digan que piensan miren: lo que are sera hacer un disparador para la tabla pero ese disárador lo unico que hara sera llamar un procedimiento en el cual hare el resto del procesos algo mas o menos asi:

Código:

Esto para el trigger:

DELIMITER |

CREATE TRIGGER lanzador AFTER INSERT ON tabla
  FOR EACH ROW BEGIN
    SET @id:=NEW.id, @productor:=NEW.productor, @labor:=NEW.labor, @superficie:=NEW.superficie
                        @fecha:=NEW.fecha;
CALL insertarComparar(@id, @productor, @labor, @superficie, @fecha)
  END
|

Y esrte para el procedimientos:

delimiter |
CREATE PROCEDURE insertarComparar (IN var_id INT, IN var_productor INT, IN var_labor VARCHAR(200), IN var_superficie DOUBLE, IN var_fecha DATE)
BEGIN

SET @sumapro:=0, @resu:=0 ;

SELECT SUM(superficie) INTO @sumapro FROM tabla WHERE productor=var_productor;
@resu=@sumapro-var_superficie;
IF @resu<0 THEN DELETE* FROM tabla WHERE id=var_id;
END IF;

END
|

Les parece que funcione, bueno como quiera lo voy a probar haber que pasa pero si les parece que falla algo les agradeceria que me dijeran.

[gnzsoloyo]

No funcionará en MySQL.
En el trigger estás llamando a un SP (llamada que no estoy seguro de que puedas hacer, no lo he probado), pero ese SP llama a una operación DML (DELETE) sobre la misma tabla que disparó el trigger que aún está ejecutándose en ese momento. Eso es una acción prohibida, fundamentalmente porque no sólo está bloqueada la tabla en sí, sino que lo haces sobre un registro que aún no se asentó (tomas los valores del NEW), ni fue liberado.

Francamente, no veo cómo puede funcionar.

[bavarol]

Iniciado por gnzsoloyo

Me refiero que si tienes un TRIGGER definido, por ejemplo, para un INSERT en la tabla A, el código de ese trigger no puede realizar INSERT, DELETE, UPDATE, ALTER o DROP sobre la misma tabla A, porque en ese momento está bloqueada.
Tampoco puede hacer una operación de clase DML (INSERT, DELETE; UPDATE) sobre una tabla B si la tabla B tiene a su vez un TRIGGER que realice una operación DML sobre la tabla A (nested process).
Lo que si puedes hacer es crear otras tablas (temporales o no) o realizar operaciones sobre los valores del nuevo registro (INSERT) o del viejo (UPDATE).
Finalmente: No se pueden crear variables de tipo TABLE porque en MySQL no existe ese tipo de dato. Existen las tablas TEMPORARY y MEMORY, que cumplen funciones parecidas.
Tampoco se puede cancelar un INSERT/ UPDATE/ DELETE en proceso desde su TRIGGER.

Como dije: Hay cosas que son incompatibles entre diferentes BDMS. Por eso las migraciones son tan complejas.

a ver, en SQL Server se llama instead of insert porque no llega a realizarse la insercion, no existe el before insert como tal en MySQL, en MySQL, te digo desde ya que yo he hecho ya varios asi y no dan ningun problema, quicir, usando el before of insert, esto es, dentro del cuerpo del trigger podemos controlar que datos se meten , finalmente los datos que van a ser un nuevo registro de la tabla seran datos procesados previamente en una tabla temporal como te digo, a lo mejor hablo de forma muy abstracta pero de un modo estilo procesado de new.loquesea + datos de la tabla temporal.

No se si me he explicado bien pero creeme, funciona y sin problemas.

No me referia a hacer un insert sobre la tabla en si, es mas bien, controlar lo nuevo, ya se que iria contra la definicion de trigger.

[bavarol]

Iniciado por gnzsoloyo

No funcionará en MySQL.
En el trigger estás llamando a un SP (llamada que no estoy seguro de que puedas hacer, no lo he probado), pero ese SP llama a una operación DML (DELETE) sobre la misma tabla que disparó el trigger que aún está ejecutándose en ese momento. Eso es una acción prohibida, fundamentalmente porque no sólo está bloqueada la tabla en sí, sino que lo haces sobre un registro que aún no se asentó (tomas los valores del NEW), ni fue liberado.

Francamente, no veo cómo puede funcionar.

En un trigger no se puede hacer una llamada a un SP.