He leído muchos puntos de vista fuertes (tanto a favor como en contra) SP o DS.sql dinámico vs procedimientos almacenados - pros y contras?
Estoy escribiendo un motor de búsqueda en C++ (backend mySQL por ahora, aunque puedo optar por un C++ ORM). No puedo decidir si escribir un SP o crear dinámicamente el SQL y enviar la consulta al motor de base de datos. #
¿Algún consejo sobre cómo decidir?
Tiene más control sobre los mecanismos fuera de la base de datos. El mayor triunfo para ocuparme de esto fuera de la base de datos es simplemente mantenimiento (en mi opinión). Sería un poco difícil controlar la versión del SP frente al código que generas fuera de la base de datos. Una cosa más para hacer un seguimiento.
Mientras hablamos del tema, es similar al manejo de migraciones de datos/esquemas. La versión/manejo de las migraciones de esquema es extremadamente compleja, si todavía no tienes un mecanismo para esto, tendrás otra cosa más que necesitarás para administrar. Todo se reduce a simplemente ser más fácil de administrar/versionar estas cosas fuera de la base de datos.
Considere el escenario donde tiene un error en su SP. Ahora necesita ser cambiado, pero luego salta a otra base de datos de desarrolladores/sandbox. ¿Qué versión es el sandbox y el SP? Ahora tienes que rastrear múltiples versiones.
Uno de los principales diferenciadores es si está escribiendo el "único frente verdadero" o si la base de datos es la pieza central de su aplicación.
Si va a tener múltiples frontales, los procedimientos almacenados tienen mucho sentido porque reduce los gastos generales de mantenimiento. Si está escribiendo solo una interfaz, los procedimientos almacenados son un fastidio, porque pierde mucha flexibilidad al cambiar su conjunto de datos ya que su front end necesita cambiar, además ahora tiene que hacer mantenimiento de código, control de versión, etc. en dos lugares . Las bases de datos son un verdadero dolor para mantenerse sincronizado con los repositorios de código.
Finalmente, si está codificando varias bases de datos (código compatible con Oracle y SQL, por ejemplo), evitaría los procedimientos almacenados por completo.
En determinadas circunstancias excepcionales, después de la creación de perfiles, determine que algunos procedimientos almacenados limitados le son útiles. Esta situación se presenta mucho menos de lo que las personas piensan que es.
Los principales escenarios cuando usted debe tener el SP es:
1) Cuando tenga conjunto muy complejo de consultas con una sobrecarga de compilación de datos y pesada deriva suficientemente bajo para que recompilación no es necesario en una base regular.
2) Cuando la lógica "Sólo Verdadero" para acceder al conjunto de datos específico es MUY complicada, necesita acceder desde varias bases de códigos diferentes en diferentes plataformas (por lo que escribir múltiples API en código es mucho más caro).
Cualquier otro escenario, es discutible, y se puede decidir de una forma u otra.
Debo decir también que los argumentos de los otros carteles sobre el control de versiones no son tan importantes en mi experiencia: tener sus SP en control de versiones es tan fácil como crear una estructura de directorios "sql/db_name" y tener secuencia de comandos "release de base de datos" que libera el código SP de la ubicación de control de la versión a la base de datos. Todas las empresas para las que trabajé tenían algún tipo de configuración como esta, centralizada por DBA o departamental administrada por desarrolladores.
Lo único que desea evitar es tener su lógica de negocio distribuida en varios niveles de su aplicación. Los DDL y DML de base de datos son lo suficientemente difíciles como para mantenerse sincronizados con una base de código de aplicación tal como está.
Mi recomendación es crear un buen esquema relacional, pero todas sus restricciones y factores desencadenantes para que los datos conserven integridad incluso si alguien va a la base de datos e intenta hacer algo a través de una línea de comandos SQL.
Ponga toda la lógica de su negocio en una aplicación o servicio que llame a SQL (estático/dinámico) y luego envuelva la funcionalidad comercial que está tratando de exponer.
Los procedimientos almacenados tienen dos propósitos que se me ocurren.
Después de que el programa se haya completado y haya sido perfilado, a menudo hay problemas de rendimiento con la versión pre 1.0. Los procedimientos almacenados ofrecen lotes de SQL sin que el tráfico tenga que ir y venir entre el DBMS y la Aplicación. Dicho esto en casos raros y extremos debido al rendimiento, es posible que algunas reglas comerciales deban migrarse al lado del Procedimiento almacenado. Asegúrese de documentar cualquier excepción a la filosofía arquitectónica en múltiples lugares prominentes.
Los procedimientos almacenados son muy poderosos cuando se usan correctamente. Tienen muchos más propósitos que los que has enumerado. A menudo tienen el mejor contexto para tomar decisiones comerciales y de validación. No es práctico y, en muchos casos, una programación francamente mala devolver grandes conjuntos de datos porque no está dispuesto a implementar la lógica en el lugar correcto. – Joe
@Joe - El lugar correcto no es la base de datos para la lógica. –
Aquí está la respuesta simple:
Si los programadores hacen tanto la base de datos y el trabajo de codificación, a mantener el SQL con la aplicación. Es más fácil de mantener de esa manera. De lo contrario, deje que los tipos DB lo manejen en SP.
+1 Lean y rápido, al igual que nos gustan esas respuestas. ;) –
No estoy de acuerdo. SQL en la aplicación significa que tiene la FORMA de reconstruir la aplicación cuando encuentra una consulta mal escrita (mal rendimiento, datos incorrectos, etc.) En la base de datos, usted modifica el proceso, y listo. – Joe
Por supuesto, su desacuerdo depende de muchos factores. Estás asumiendo una aplicación monolítica que se distribuye. En ese caso, sí, probablemente tengas razón. Pero una aplicación bien construida NO es un gran ejecutor que necesita ser recompilado en cada cambio. Al igual que no usaría una tabla para almacenar todos sus datos para una aplicación. – Sophtware
DS es más flexible. El enfoque SP hace que su sistema sea más manejable.
procedimientos almacenados son ideales para:
SQL dinámico es ideal para:
IN cláusulas con los valores especificados por el usuarioEllos resuelven diferentes problemas, de verdad. Utilice el que sea más apropiado para la tarea en cuestión, y no se limite a uno solo o al otro. Después de trabajar en el código de la base de datos por un tiempo, comenzará a tener una percepción más intuitiva de estas cosas; Te encontrarás golpeando un nido de cuerdas para una consulta y pensarás, "esto debería ir en un procedimiento almacenado".
Nota final: como esta pregunta implica un cierto nivel de inexperiencia con SQL, me siento obligado a decir, , no olvide que aún necesita parametrizar sus consultas cuando escriba SQL dinámico. Los parámetros no son solo para procedimientos almacenados.
Esto es BS. No es más difícil controlar la versión del código SQL en comparación con el código C++. En muchos sentidos, es mucho más fácil revisar las cosas en el DB; altere un procedimiento almacenado, y listo, en lugar de recompilar y volver a implementar bibliotecas y ejecutables. – Joe