Ver Mensaje Individual
  #4 (permalink)  
Antiguo 15/08/2011, 05:50
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: Procedimientos almacenados y Triggers

Cita:
Un trigger es una acción automatica de evento, por lo que, logicamente, no resive parámetros y generalmente sirve para dar mantenimiento a la base de datos ¿?.
No necesariamente.
Los triggers se usan para automatizar alguna tarea que deba hacerse siempre, de la misma forma y que no necesite ser supervisada o activada de otro modo. No hay una regla que nos diga que se usan para una cosa u otra. Eso depende exclusivamente de las necesidades del sistema que esa base de datos alimenta.
Hay gente que las usa para crear logs de auditoría, otros lo usan para no tener que programar actualizaciones de ciertos datos, yo los he usado a veces para numerar los subitems de una factura, o para insertar ciertos datos cuando el INSERT o UPDATE tomen ciertos valores en un campo dado.
Como te digo, no hay una regla fija; son una herramienta que se usa cuando se necesita.
Cita:
Un stored procedure es una función personalizable y reutilizable como en cualquier lenguaje de programación, parecidas(en su uso) a las funciones nativas de MySQL ¿?.
No.
Un stored procedure es una rutina escrita en SQL, con el agregado de poder usar algunas clausulas sólo para SP. El objetivo de un SP es hacer tareas complejas con secuencias de consultas. No se parece en ese sentido a una funcion nativa de MySQL.
Lo que sí existe es la posibilidad de hacer STORED FUNCTIONS, que siguen estando programadas en SQL, pero devuelven un único valor.
Estas son una subclase de los stored procedures, pero como los SP, sólo existen en la base de datos donde se crean. No son parte de las funciones de MySQL.
Alguna gente usa los SP para aumentar la seguridad contra el sql-injection, ya que son invulnerables al mismo. Otros los usan para restringir el acceso de los usuarios, ya que se peude hacer que un usuario sólo pueda ejecutar SP y no leer tablas, con lo que aumentas la seguridad de la base indirectamente.
Yo lo uso para estas dos cosas y otras más, como por ejemplo tareas de multiples consultas que generan reportes completos (la salida final es una tabla), especialmente cuando tengo que trabajar con tablas de tipo TEMPORARY. En este sentido, mis SP suelen tener más de 150 líneas y me resultan más eficientes que hacerlos sentencia por sentencia, usando programación.

¿Se ve un poco mejor el tema?
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)