Triggers en MySQL

[ChUKii]

Buenas!

A ver me ha surgido una problemilla y nose si con triggers se podria solucionar...

Necesito enviar a un puerto tcp de otra maquina unos datos cada vez que se hace un INSERT en una BD MySQL.
Nose si esto se puede hacer directamente desde MySQL usando triggers o si se podria ejecutar un proceso que fuese el que se conectase a la otra maquina para hacer el envio de la informacion...

Es que por lo que he leido me da la impresion de que los triggers solo lanzan otras consultas cuando sucede un evento...

:brindis::brindis:

Edito:

Creo que he dado con la única solucion


Write an insert trigger which duplicates inserted rows to a secondary table. Periodically poll the secondary table for rows with an external application/cronjob; if any rows are in the table, delete them and do your processing (or set a 'processing started' flag and only delete from the secondary table upon successful processing).

This will work very nicely for low to medium insert volumes. If you have a ton of data coming at your table, some kind of custom trigger in C is probably your only choice.


Es decir:

Crear una tabla que se vaya rellenando cada vez que se lanza el trigger y que a su vez sea leida y vaciada por mi proceso para asi conseguir que sea todo mas rapido...

[Malenko]

Osti, no sabia que la GP2X podía tener MySQL! :S

En cuanto a tu problema, esa sería una solución. Otra sería meter el flag en la tabla primera, directamente. Yo lo que haría sería por ejemplo poner un campo de entero, o una fecha, etc. que pueda ser null. De forma que los inserts que la atacan no puedan petar.

Luego, con una aplicación o un cron job de esos, atacas la tabla sobre los registros que tienen ese campo a NULL. Luego acuerdate de poner a algun valor para no volver a atacarlos.

Yo es la técnica que uso, porque piensa que los triggers te retrasarán los inserts y dependiendo de la aplicación puede ser j*dido.

[ChUKii]

Ops, me dio la impresion de que era la seccion de "Programacion en general" no de la GP2X.

Me gusta tu idea, lo que pasa es que es una tabla un poco tocha como para recorrerla cada vez que la aplicacion quiera ver si hay algo nuevo con el campo flag a null... por eso habia pensado en usar triggers...

Como lo ves? O es una chorrada y no va a ser mas optimo?

Como la aplicacion realizaria las consultas periodicamente no me importa que los triggers tarden un poco mas siempre y cuando eso no sobrecargue la BD.

:brindis::brindis:

Edito:

Sigo investigando...Procedimientos almacenados y UDF

[Malenko]

Tocha cuantos millones de registros son? Piensa que puedes usar un indice sobre el campo para agilizar (y mucho) la consulta.

Ojo, que la opción de usar una segunda tabla no es nada mala. De hecho yo la uso para una aplicación en concreto, pero es una tabla que es MUY MUY grande (se insertan facilmente unos 10 o más registros por segundo).

[ChUKii]

Prefiero no hacer un count que esta ahora mismo en produccion jeje pero se insertan 1 cada 2 segundos mas o menos...

Lo que mejor pinta tiene de lo que estoy leyendo es crear una funcion (UDF) y llamarla desde un trigger cada vez que se produzca un insert con una cierta condicion y ya que sea esa funcion la que lance el proceso de envio al socket :), no se sobrecargaria nada la BD y seria inmediato el envio de los datos nuevos :D


:brindis::brindis:

[animanegra]

Si tu problema es que esta en produccion y no quieres retrasar consultas por no activas los logs?? Lees de los logs la ultima lina y miras si tienes un insert. Si lo tienes mandas un pacquete al otro ordenador y listos.

Ademas lo podrias hacer supersencillo con bash y usando el nc.