MySQL - Procemientos almacenados Vs. querys embebidos

Hola gente:
Tengo que encarar el desarrollo de una pagina web dinámica (PHP + MySql) la duda se me genera en lo siguiente: que es mejor, usar los querys embebido dentro del PHP o crear Procedimientos Almacenados para llamarlos luego.? espero sugerencias.
Desde ya muchas gracias.!
Italo

Yo no haria ni una ni la otra.
Lo que yo haria seria crearme un modulo o clase en donde almacenar funciones
php que ejecuten las queries.
Luego desde el php invocas a dichas funciones.
Saludos
Leandro

Hola Leandro: gracias por responder, la idea sería armar lo que llaman Capa de Datos.?
por supuesto de ser asi, tendre que informarme como armar dicha capa y cuales son sus principales beneficios. Sigo aceptando sugerencias.
Muchas gracias.!
Italo

Exacto.
No hay nada de extraño en lo que le llamas armar la capa.
La capa simplemente es un archivo php que tiene las funciones o la clase definida.
Entonces en la web donde vayas a usar las queries lo que haces es un require
del php en el que estan declaradas las funciones o donde definiste la clase.
Y luego haces uso de las funciones o de la clase

ejemplo con funciones
________
A.php
(Php donde declaras las funciones que hacen las consultas y retornan un resultado)

function retornarDatos(){

return ....

}

_______________

B.php
(Php en donde precisas hacer una consulta a la base de datos)
require_once "A.php";

$resultado = retornarDatos();

...
_________________

Como ves para hacer uso de una funcion lo unico que tienes que hacer es
incluirla o importarla donde vayas a utilizarla.
Para el caso de definas la capa como una clase (para usar OOP) lo unico que
cambia es el archivo A.php que en lugar de tener funciones sueltas tienes
una clase definida con metodos y atributos
y en el archivo B.php cuando la vayas a usar primero tienes que crear el objeto
para despues invocar sus funciones.
Si no sabes OOP te recomiendo que lo hagas como ilustre el ejemplo.

Saludos
Leandro.

Hola Leandro:
muy clara tu explicacion, muchas gracias.!
Saludos.!
Italo

Esa e la visión de los programadores de aplicaciones, pero hay varias consideraciones para hacer:
- Los stored procedures se ejecutan siempre en servidor, y de esa forma permiten liberar las máquinas cliente de recursos. Esto hace que incluso si una aplicación cliente corre desde una máquina de baja performance, la respuesta pueda ser muy veloz si la base se encuentra en un servidor mucho más potente, porque el proceso de consulta no se realiza en el cliente, sino en el servidor.
- Los stored procedures son las formas más seguras de ejecutar una gran cantidad de operaciones, que no necesariamente son simples consultas de SELECT. Con ellos se realizan tareas de gran complejidad que requierirían una enorme cantidad de llamadas a la base y/u operaciones de la aplicación. Como los SP residen en la base y operan solamente en ella, el uso de SP libera recursos para la palicación que de otro modo reducirían la optimizaciuón de la aplicación.
- Como el uso de SP requiere solamente de permisos de EXECUTE, esto permite que se pueda administrar a los usuarios con mucha mas profundidad, restringiendo el acceso de los mismos a secciones críticas de la base. Esto mismo funciona para el caso de las VIEW.
- Los stored procedures son invulnerables al sql-injection, ya que solamente pueden recibir parámetros, y no contienen sentencias accesibles desde fuera. Si el parámetro es un sql-injection, el SP simplemente no opera, y en todo caso, no puede hacer más tareas que las que están programadas.
- Los SP solamente pueden ser programados y cargados en la base por usuarios de alto nivel, y sólo con permisos especiales pueden ser cargados en forma remota, lo que permite controlar incluso que puedan ser modificados por personas no autorizadas. Con esto te puedes asegurar que los que haces no puedan modificarse así nomas.
- Los SP no se copian en un backup manual si no sabes cómo hacerlo, por lo que solamente usando aplicaciones específicas o conociendo los comandos peudes acceder a su estrucutra.

Resumiendo: Si quieres aumentar la seguridad, evitar el sql-injection, incrementar la performance de las consultas, y realizar largas y complejas operaciones de consulta, USA STORED PROCEDURES.

Los stored procedures son de gran ayuda a la
hora de controlar la insercion de datos en la
base de datos.

Tienen un fuerte uso en la validacion de las inserciones
y que éstas respeten las restricciones de integridad
existentes en la base de datos ( como ser: no se puede
insertar tal tupla si tal otra no esta insertada en otra tabla, etc.).

Las aplicaciones web no utilizan stored procedures para
consultar datos a la base ( como ser una empresa que venda
libros que retorne la info. acerca de los libros ),
lo que se hace es dividir la aplicacion en basicamente
3 capas, en donde una de ellas es la capa de persistencia
que se comunica con la base de datos y devuelve los datos para
ser procesados y mostrados por el resto de las capas.

Es más, la mayoria de la gente que no son informaticos ni siquiera utiliza capas,
simplemente embebe las consultas en los html, cosa que esta
mal porque si por ej. se tiene que cambiar de motor de base
de datos usando capas jamas tendre que modificar las paginas
html,ni las consultas tampoco si usamos sql,
lo unico que tendre que modificar seria la capa de persistencia.
(porque modifico la forma en que me conecto a la base)
Lo que implica un impacto mucho menor.
Si utilizamos stored procedures tendre que volver a escribir
todas las consultas nuevamente , porque estas estan en stored procedures.
Y Cada motor de base de datos tiene su sintaxis.

Es muy cierto todo lo que dice el usuario acerca de los
stored procedures acerca de la perfomance etc., pero el uso de los stored procedures
que el menciona para webs NO es valido.

Les dejo un link en donde explica los usos:

http://es.wikipedia.org/wiki/Procedimiento_almacenado

En cuanto a la seguridad, quien se encarga de los sql-inyection
es la aplicacion, la aplicacion es que tiene que ser segura,
no voy a usar stored procedures para prevenir sql-inyections
para eso está la aplicacion, es la aplicacion quien debe
proteger del exterior. Una vez que tengo los datos validados
(validados en el sentido de que no es codigo malicioso)
podria usar stored procedures para validar las restricc. de
integridad, a lo que comunmente se le llama "triggers".

Es simplemente mi opinion, respeto la opinion del otro
usuario pero discrepo totalemente con ella .

Saludos
Leandro.

Muchas gracias.! la discrepancias (cuando se hacen con respeto) son realmente enriquecedoras, sus opiniones me han abierto distintos caminos. Estuve mirando el link, y en realidad mas alla de las ventajas de los SP, creo que no los utilizare.
Una vez mas muchas gracias.!
Italo

yo estoy en la misma, tengo una aplicacion vieja en vb6 y funciona en su totalidad con SP, ahora tengo que migrarla a la web y me dicen que ya no es valida esa forma.

Entiendo las 2 posturas, pero cual seria el problema de seguir trabajando con SP, ya que la aplicacion tiene mas de 300 SP. ???

Excelente explicacion