lógica en bases de datos

[gnzsoloyo]

Vamos a tratar e aclarar algunos conceptos...
Una de las principales cosas que aporta la integridad referencial es asegurarte a nivel estructural, que la consistencia de los datos se mantiene evitando problemas con las relaciones entre tablas. Pero ese aseguramiento no implica que le derives a la base la tarea de crear u obtener por sí misma (via rutinas en SQL) los datos necesarios para sostenerlas.
No.
El objetivo, en ese contexto, es impedir que el programador cometa errores de consistencia de datos, haciendo que la propia base contenga ciertas rutinas de verificación previas al almacenamiento.
Pero la responsabilidad de no enviar datos basura a la base sigue siendo siempre del desarrollador. Es él quien tiene que hacer todas las validaciones previas, y todas las consultas previas a la base, para obtener los datos necesarios para una inserción o actualización exitosa. No la base.
Eso es lo que se hace en las aplicaciones empresariales, porque no sólo puedes poner datos inconsistentes en una tabla, sino que mientras lo haces estás enviando datos basura, con lo que recargas al sistema e transacciones que están condenadas al fracaso, mientras que las operaciones válidas quedan en espera.
¿Se entiende la idea?

El hecho de que no exista interidad referencial con tablas MyISAM pone un problema adicional a los programadores: crear la secuencia de llamadas a la base que permita asegurarse que los datos que se almacenaron cumplen con los requisitos de integridad de cada caso. Pero eso no es tan complicado como parece.
Puntualmente, los TRIGGER no son una buena opción, porque en MySQL los TRIGGER sólo tienen como datos de entrada los propios de la tabla donde se realiza la operación. Nada más. Por ende, si los datos entrantes no son suficientes para realizar una verificación contra otra... ¿qué haces?
No sirve.
En versiones anteriores, no ea posible disparar un error funcional en MySQL en un TRIGGER, pero afortunadamente ahora si (ver SIGNAL en manuales recientes), por lo que se puede hacer ciertas validaciones, pero como dije, no se puede buscar datos, a menos que los propios valores de entrada sean suficientes para eeso.
Entonces qué camino se puede elegir?
Simple.
Lo puedes ver en má de un manual sobre desarrollos de capa de datos: Stored procedures.
Los SP son el modo en que se implementa lógica programada en una base de datos. Para eso se construyeron, pero no se usan porque si.
¿Cuándo conviene usarlos?
Cuando:
1) Tienes todos los datos suficientes para realizar la validaciones y obtencion de datos intermedios del insert .
2) Cuando no se requiera ninguna nueva interacción o decisión del usuario para realizar ningún otro paso.
3) Cuando lo único que se desee es obtener una respuesta de éxito o fracaso, sea esta un valor dado (codigo de exito) o bien un set de datos (tabla).
Nunca se usan para resolver cosas que los lenguajes de programación hacen mejor. Jamás.

¿Se va entendiendo la idea?