Estado de cuenta preparado frente a procedimiento almacenado

Question

Si está utilizando php5 y mysql5, ¿existe una ventaja sustancial al usar procesos almacenados sobre declaraciones preparadas? (He leído en algún lugar que puede no obtener ganancias sustanciales de rendimiento del programa almacenado mysql5)

Answer 1

No son realmente lo mismo: con los procedimientos almacenados, la lógica de la base de datos reside dentro de la base de datos. Las declaraciones preparadas básicamente evitan volver a analizar las consultas si se llaman varias veces; el beneficio de rendimiento puede variar mucho.

La elección de utilizar una u otra depende realmente de su situación específica. Realmente no uso procs almacenados ya que me gusta tener toda mi lógica en un solo lugar.

Answer 2

No estoy familiarizado con php, pero en general los procedimientos almacenados ya están "compilados", por lo que pueden producir un rendimiento marginalmente más rápido en una sentencia sql.

Aunque mi preferencia generalmente es seguir con el SQL desde la administración del código/implementación y la perspectiva de la prueba unitaria.

Answer 3

La ventaja sustancial de los procedimientos almacenados es que sus datos no cruzan una capa (en este caso sería la capa PHP/MySQL) antes de que se le pueda aplicar la lógica. Algunas consultas pueden requerir varias instrucciones de selección, que es más lenta a través de PHP que dentro de MySQL.

Ahora, como señala tobyhede, es bueno tener toda la lógica en un solo lugar. Pero he trabajado en proyectos donde no era realista consultar los datos requeridos usando PHP; tenía que hacerse a través de un procedimiento almacenado.

Answer 4

Puede que no sea el caso o que valga la pena mencionarlo aquí, pero los procedimientos almacenados también son "portátiles" en el caso de que sean independientes del idioma. Puede llamar a los mismos procedimientos almacenados en su base de datos desde, por ejemplo, Java como lo haría con PHP. Debido a que los procedimientos residen en la base de datos, cualquier cosa con acceso a la base de datos puede consultarlos de la misma manera.

Answer 5

Algunas de las ventajas de los procedimientos almacenados:

• portátil entre las lenguas
• interfaz Podría decirse simplificado y, a veces las ganancias de rendimiento para consultas complejas y en especial la consulta múltiple transacciones (prueba!)
• mediante la exposición de una interfaz en lugar de tablas , se puede utilizar para mejorar la seguridad y la integridad

Algunas desventajas de los procedimientos almacenados:

• pone la lógica de negocio en la base de datos - complica el diseño, el lugar extra para realizar un seguimiento de control de versiones y la solución de problemas
• pérdidas de rendimiento en algunos situaciones
(prueba!)
• Menos portátil entre bases de datos

No creo que exista una sola respuesta generalizada para esta pregunta porque hay pros y contras dependi ng en la situación. Si sigue principios como la simplicidad, DRY, pruebas y evitar la optimización prematura, es probable que termine bien.

Answer 6

Comenzaré diciendo que no me gusta la idea de los procedimientos almacenados, prefiero ir a la ruta de declaraciones preparadas. En este caso particular, creo que también está comparando manzanas con naranjas ... ambas están allí para llenar funciones diferentes ...

Consideraré solo el procedimiento almacenado si la aplicación está basada en el 95% de la base de datos solo entonces lo hace tiene sentido tener algo de la lógica en el DB.

Answer 7

Los procedimientos almacenados hacen aplicaciones sentido de nivel profesional (IE de nivel empresarial) en la que:

1. desea permitir su ingeniero base de datos para optimizar las consultas para obtener un rendimiento
2. Quieres abstraen la complejidad de las consultas a la simple API
3. QUIERE su lógica distribuida, porque parte de lo que sucede en la base de datos puede ser propiedad intelectual que no desea exponer a otras partes
4. QUIERE que su lógica se distribuya, porque esa es la naturaleza de distribut ed, computación
5. n-tier es posible que desee el ingeniero de base de datos o DBA para modificar el esquema sin modificar el código de la aplicación (procedimientos almacenados, por la prestación de API, proporcionar una capa de abstracción)

Hay otras razones .

Las declaraciones preparadas son mejores para el trabajo realizado dentro de una sesión. Pero si se toma el tiempo de crear una declaración preparada, esencialmente ha hecho todo lo necesario para crear un procedimiento almacenado. La diferencia es que el procedimiento almacenado está disponible en varias sesiones (sujeto a GRANTS en la base de datos).

Lo que no puedo entender es que si tiene la opción de proc almacenado frente a una declaración preparada, ¿por qué se molestaría con las declaraciones preparadas? La mayoría de las discusiones entre SP y PS parecen enfocarse en cuáles son las diferencias entre ellos, no en por qué usar uno frente a otro. Eso siempre parece reducirse a "depende de lo que estás tratando de hacer". Pero no he visto una descripción bien organizada de: use un proceso si necesita VS use una declaración si necesita ....